Nick Piggin wrote:

>> The lazy freeing is aimed at avoiding page faults on memory
>> that is freed and later realloced, which is quite a common
>> thing in many workloads.
> 
> I would be interested to see how it performs and what these
> workloads look like, although we do need to fix the basic glibc and
> madvise locking problems first.

The attached graph are results of running the MySQL sysbench
workload on my quad core system.  As you can see, performance
with #threads == #cpus (4) almost doubles from 1070 transactions
per second to 2014 transactions/second.

On the high end (16 threads on 4 cpus), performance increases
from 778 transactions/second on vanilla to 1310 transactions/second.

I have also benchmarked running Ulrich's changed glibc on a vanilla
kernel, which gives results somewhere in-between, but much closer to
just the vanilla kernel.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.