This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: add locking to thread cache

On Wed, 2016-01-27 at 09:44 -0800, JÃrn Engel wrote:
> On Wed, Jan 27, 2016 at 10:05:33AM +0000, Szabolcs Nagy wrote:
> > 
> > portable code does not need the fix, but all users
> > of the api are affected by the overhead of the fix.
> Sorry, but you have no idea what you are talking about.  The overhead of
> the fix is _negative_.  Users _want_ to be affected.
> The reason why free() is not signalsafe is that it spins on an
> arena-lock.  If the same thread already holds that lock, you have a
> classic deadlock.  By not spinning on the lock you make code run faster.
> You also fix the signal-induced deadlock.
> Ok, for thread-cache there is some overhead.  Without signal-safety you
> wouldn't need a lock for the thread-cache at all.  But here I call
> bullshit again, because I had the same concerns.  Then I measured and
> could not demonstrate any performance impact.
> "If you cannot measure it, it does not exist."
> You might disagree philosophically, but if an engineers goes out of his
> way to measure a certain effect and finds nothing, that effect hardly
> matters in any practical way.

Then it should be sufficient if you can describe what you actually
measured to convince Szabolcs; if your measurement is as good as you
seem to say it is, it should be obvious why his (and your prior)
concerns are unfounded.  Up to now, you just stated that you did measure

I'd also like to kindly point out that we're not on LKML here.  We all
will understand you better if you provide sounds arguments and provide
the necessary background information instead of if you "call bullshit".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]