Re: vmscan.c heuristic adjustment for smaller systems

William Lee Irwin III
2004-04-18T01:59:23Z

Marc Singer <elf@buici.com> wrote:
>> 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.

On Sat, Apr 17, 2004 at 04:51:51PM -0700, Andrew Morton wrote:
> Which tends to imply that the VM is not reclaiming any of that nfs-backed
> pagecache.

The observation that prompted the max() vs. addition was:

On Sat, Apr 17, 2004 at 10:57:24AM -0700, Marc Singer wrote:
> I don't think that's the whole story. I printed distress,
> mapped_ratio, and swappiness when vmscan starts trying to reclaim
> mapped pages.
> reclaim_mapped: distress 50 mapped_ratio 0 swappiness 60
> 50 + 60 > 100
> So, part of the problem is swappiness. I could set that value to 25,
> for example, to stop the machine from swapping.
> I'd be fine stopping here, except for you comment about what
> swappiness means. In my case, nearly none of memory is mapped. It is
> zone priority which has dropped to 1 that is precipitating the
> eviction. Is this what you expect and want?

Marc Singer <elf@buici.com> wrote:
>> 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?

On Sat, Apr 17, 2004 at 04:51:51PM -0700, Andrew Morton wrote:
> I'd assume that setting swappiness to zero simply means that you still have
> all of your libc in pagecache when running ls.
> What happens if you do the big file copy, then run `sync', then do the ls?
> Have you experimented with the NFS mount options? v2? UDP?

I wonder if the ptep_test_and_clear_young() TLB flushing is related.

-- wli