Re: What to expect with the 2.6 VM

Andrea Arcangeli
2003-07-01T04:04:59Z

On Tue, Jul 01, 2003 at 03:29:54AM +0000, Rik van Riel wrote:
> On Tue, 1 Jul 2003, Andrea Arcangeli wrote:
>
> > Also think if you've a 1G box, the highmem list would be very small and
> > if you shrink it first, you'll waste an huge amount of cache. Maybe you
> > go shrink the zone normal list first in such case of unbalance?
>
> That's why you have low and high watermarks and try to balance
> the shrinking and allocating in both zones. Not sure how
> classzone would influence this balancing though, maybe it'd be
> harder maybe it'd be easier, but I guess it would be different.
>
> > Overall I think rotating too fast a global list sounds much better in this
> > respect (with less infrequent GFP_KERNELS compared to the
> > highmem/pagecache/anonmemory allocation rate) as far as I can tell, but
> > I admit I didn't do any math (I didn't feel the need of a demonstration
> > but maybe we should?).
>
> Remember that on large systems ZONE_NORMAL is often under much
> more pressure than ZONE_HIGHMEM. Need any more arguments ? ;)

we run out of ZONE_NORMAL but until we run oom it doesn't mean we shrink
it frequently, those are pretty static allocations (the mem_map is the
most static and in turn the biggest one ;), but it doesn't mean, we
allocate 500M and release 500M in a few seconds of zone normal. Also
many like selects are released and reallocated before you've a chance to
need a shrink.

The shrinkers are the ones allocating huge chunks in a loop and never
releasing it except through the VM (an updatedb would do it with the
lots of metadata overhead, but it's not really as common as the
highmem ones).

So your argument about ZONE_NORMAL being uner much more pressure doesn't
make sense to me, in line with my answer to Andrew that the frequency
of allocations (NOTE: without later explicit deallocations but relaying
on the cache collecting in the vm).

Andrea