Re: 4g/4g for 2.6.6

[Ingo Molnar <mingo@elte.hu>]

* Andrew Morton <akpm@osdl.org> wrote:

> > Btw, you're right about the VMAs.  Looking through customer
> > stuff a bit more the more common issues are low memory being
> > eaten by dentry / inode cache - which you can't always reclaim
> > due to files being open, and don't always _want_ to reclaim
> > because that could well be a bigger performance hit than the
> > 4:4 split.
> 
> I did some testing a year or two back with the normal zone wound down
> to a few hundred megs - filesytem benchmarks were *severely* impacted
> by the increased turnover rate of fs metadata pagecache and VFS
> caches.  I forget the details, but it was "wow".

and it's not only the normal workloads we know about - people really do
lots of weird stuff with Linux (and we are happy that they use Linux and
that Linux keeps chugging along), and people seem to prefer a 10%
slowdown to a box that locks up or -ENOMEM's. I'm not trying to insert
any unjustified fear, 3:1 can be ok with lots of RAM, but it's _clearly_
wishful thinking that 32 GB x86 will be OK with just 600 MB of lowmem.
600 MB of lowmem means a 1:80 lowmem to RAM ratio, which is insane. Yes,
it will be OK with select workloads and applications. With 4:4 it's 3.4
GB lowmem and the ratio is down to a much saner 1:9, and boxes pushed
against the wall keep up better.

(but i wont attempt to convince Andrea - and i'm not at all unhappy that
he is trying to fix 3:1 to be more usable on big boxes because those
efforts also decrease the RAM footprint of the UP kernel, which is
another sensitive area. These efforts also help sane 64-bit
architectures, so it's a win-win situation even considering our
disagreement wrt. 4:4.)

> I'm suspecting we'll end up needing mempools (or something) of 1- and
> 2-order pages to support large-frame networking.  I'm surprised there
> isn't more pressure to do something about this.  Maybe people are
> increasing min_free_kbytes.

hm, 1.5K pretty much seems to be the standard. Plus large frames can be
scatter-gathered via fragmented skbs. Seldom is there a need for a large
skb to be linear.

	Ingo