Re: vmscan.c heuristic adjustment for smaller systems

[William Lee Irwin III]

Marc Singer <elf@xxxxxxxxx> 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@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/