Re: lowmem_reserve (replaces protection)

[Andrea Arcangeli <andrea@novell.com>]

On Tue, Oct 26, 2004 at 10:33:35PM -0700, Andrew Morton wrote:
> Andrea Arcangeli <andrea@novell.com> wrote:
> >
> > So after allocating the highmem pages we invoke kswapd
> >  again
> 
> Nope.  We don't wake kswapd until the lower zones are below pages_low as
> well.  Then we rebalance all the zones which are below pages_high.

the lower zones will always be below pages_low+lowmem_reserve forever
since the reservation is 800M of ram.

The allocator isn't using pages_low, the allocator is always using
pages_low+lowmem_reserve. This is why only highmem will be allocated and
then immediatly kswapd will be invoked again.

the lower zones are above pages_high all the time, but they're also
below pages_low+lowmem_reserve all the time.

I'm not talking about 2.6.9 with protection disabled, I'm talking about
2.6.9+lowmem_reserve enabled.

So there will definitely be a rolling on the highmem, but it's probably
ok see below:

> As I say: run a workload mix and monitor /proc/vmstat:
> 
> 	pgscan_kswapd_high
> 	pgscan_kswapd_normal
> 	pgscan_kswapd_dma
> 
> These should be increasing at rates which are proportional to their size,
> if most allocations have __GFP_HIGHMEM.

they should yes. And this is also why it shouldn't be a problem this
behaviour of kswapd despite the rolling (after all we're shrinking cache
from the lower zones too, except the highmem cache will be rolled).

I'll try to measure the above soon (and I already applied it to all
relevant trees so it'll get some beating, since the aging details are
somewhat less severe than potential deadlocks or oom kills with lots of
ram and ptes, espcially now without the incremental min we have to
enable it).