Re: vmscan.c heuristic adjustment for smaller systems

From: Marc Singer
Date: Sat Apr 17 2004 - 18:32:46 EST

On Sat, Apr 17, 2004 at 04:21:25PM -0700, Andrew Morton wrote:
> Marc Singer <elf@xxxxxxxxx> wrote:
> >
> > I'd say that there is no statistically significant difference between
> > these sets of times. However, after I've run the test program, I run
> > the command "ls -l /proc"
> >
> > swappiness
> > 60 (default) 0
> > ------------ --------
> > elapsed time(s) 18 1
> > 30 1
> > 33 1
> How on earth can it take half a minute to list /proc?

I've watched the vmscan code at work. The memory pressure is so high
that it reclaims mapped pages zealously. The program's code pages are
being evicted frequently.

I would like to show a video of the ls -l /proc command. It's
remarkable. The program pauses after displaying each line.

> > This is the problem. Once RAM fills with IO buffers, the kernel's
> > tendency to evict mapped pages ruins interactive performance.
> Is everything here on NFS, or are local filesystemms involved? (What does
> "mount" say?)

# mount
rootfs on / type rootfs (rw)
/dev/root on / type nfs (rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)

I've been wondering if the swappiness isn't a red herring. Is it
reasonable that the distress value (in refill_inactive_zones ()) be

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at