Re: Bug with shared memory.

["Martin J. Bligh" <Martin.Bligh@us.ibm.com>]

> For the memclass_related_bhs() fix in -aa, that's in the testing TODO
> list of Martin (on the multi giga machines), he also nicely proposed to
> compare it to the other throw-away-all-bh-regardless patch from Andrew
> (that I actually didn't seen floating around yet but it's clear how it
> works, it's a subset of memclass_related_bhs). However the right way to
> test the memclass_related_bhs vs throw-away-all-bh, is to run a rewrite
> test that fits in cache, so write,fsync,write,fsync,write,fsync. specweb
> or any other read-only test will obviously perform exactly the same both
> ways (actually theoretically a bit cpu-faster in throw-away-all-bh
> because it doesn't check the bh list).

The only thing that worries me in theory about your approach for this
Andrea is fragmentation - if we try to shrink only when we're low on
memory, isn't there a danger that one buffer_head per page of slab
cache will be in use, and thus no pages are freeable (obviously this
is extreme, but I can certainly see a situation with lots of partially used
pages)? 

With Andrew's approach, keeping things freed as we go, we should
reuse the partially allocated slab pages, which would seem (to me)
to result in less fragmentation?

Thanks,

M.