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 01/27/2016 12:44 PM, 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.

My mantra is slightly different:

"If others cannot measure it, your performance gains don't exist."

We are always looking for microbenchmark contributions that others
can run objectively to evaluate any such changes.


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