Re: vmscan.c heuristic adjustment for smaller systems

[Marc Singer <elf@buici.com>]

On Sat, Apr 17, 2004 at 04:51:51PM -0700, Andrew Morton wrote:
> Marc Singer <elf@buici.com> wrote:
> >
> > On Sat, Apr 17, 2004 at 04:21:25PM -0700, Andrew Morton wrote:
> > > Marc Singer <elf@buici.com> 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.
> 
> Which tends to imply that the VM is not reclaiming any of that nfs-backed
> pagecache.

I don't think that's the whole story.  They question is why.

> > I've been wondering if the swappiness isn't a red herring.  Is it
> > reasonable that the distress value (in refill_inactive_zones ()) be
> > 50?
> 
> I'd assume that setting swappiness to zero simply means that you still have
> all of your libc in pagecache when running ls.

Perhaps.  I think it is more important that it is still mapped.

> 
> What happens if you do the big file copy, then run `sync', then do the ls?

It still takes a long time.  I'm watching the network load as I
perform the ls.  There's almost 20 seconds of no screen activity while
NFS reloads the code. 

> 
> Have you experimented with the NFS mount options?  v2? UDP?

Doesn't seem to matter.  I've used v2, v3, UDP and TCP.

I have more data.

All of these tests are performed at the console, one command at a
time.  I have a telnet daemon available, so I open a second connection
to the target system.  I run a continuous loop of file copies on the
console and I execute 'ls -l /proc' in the telnet window.  It's a
little slow, but it isn't unreasonable.  Hmm.  I then run the copy
command in the telnet window followed by the 'ls -l /proc'.  It works
fine.  I logout of the console session and perform the telnet window
test again.  The 'ls -l /proc takes 30 seconds.

When there is more than one process running, everything is peachy.
When there is only one process (no context switching) I see the slow
performance.  I had a hypothesis, but my test of that hypothesis
failed.