From: Ingo Molnar

Apparently our thread-creation performance has gone down the tubes again,
because the mm.free_area_cache search heuristic broke.

The initial, more naive hole-cache patch helped the testcode in the
beginning.  Then after some point glibc started creating a 'small hole' in
the vmas, which hole was _below_ the thread stacks, and which hole thus
prevented the intended operation of the cache.

The new code solves the problem by relaxing the 'smallest address hole cache'
rule a bit, the cache is now not re-set at every get_unmapped_area() time,
it's only re-set during unmaps.  It's also re-set if there are no allocatable
mappings at all - ie.  correctness is not affected.