Re: ~500 megs cached yet 2.6.5 goes into swap hell

[Marc Singer <elf@buici.com>]

On Wed, Apr 28, 2004 at 09:33:59PM -0700, Andrew Morton wrote:
> Marc Singer <elf@buici.com> wrote:
> >
> > It could work differently from that.  For example, if we had 500M
> > total, we map 200M, then we do 400M of IO.  Perhaps we'd like to be
> > able to say that a 400M page cache is too big.
> 
> Try it - you'll find that the system will leave all of your 200M of mapped
> memory in place.  You'll be left with 300M of pagecache from that I/O
> activity.  There may be a small amount of unmapping activity if the I/O is
> a write, or if the system has a small highmem zone.  Maybe.

Are you sure?  Isn't that what the other posters are winging about?
They do lots of IO and then they have to wait for the system to page
Mozilla back in.

> Beware that both ARM and NFS seem to be doing odd things, so try it on a
> PC+disk first ;)

Yeah, I know that there is still something odd in ARM-land.  I assume
that the other posters are using IA32. 

> No, the system will only start to unmap pages if reclaim of unmapped
> pagecache is getting into difficulty.  The threshold of "getting into
> difficulty" is controlled by /proc/sys/vm/swappiness.

What constitutes 'difficulty'?  Perhaps this is rhetorical. 

> > I've read the source for where swappiness comes into play.  Yet I
> > cannot make a statement about what it means.  Can you?
> 
> It controls the level of page reclaim distress at which we decide to start
> reclaiming mapped pages.
> 
> We prefer to reclaim pagecache, but we have to start swapping at *some*
> level of reclaim failure.  swappiness sets that level, in rather vague
> units.

I'm not sure I see why we have to swap.  If have of memory is mapped,
and the user is using those pages with some frequency, perhaps we
should never reclaim mapped pages.