Messages in this thread | | | Date | Sat, 17 Apr 2004 17:23:43 -0700 | From | Marc Singer <> | Subject | Re: vmscan.c heuristic adjustment for smaller systems |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |