Re: [PATCH 2/3] vmscan: make mapped executable pages the firstclass citizen

[Wu Fengguang]

On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > > > the original size - during the streaming IO.
> > > > 
> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > > > process.
> > > 
> > > hmmm.
> > > 
> > > about 100 page fault don't match Elladan's problem, I think.
> > > perhaps We missed any addional reproduce condition?
> > 
> > Elladan's case is not the point of this test.
> > Elladan's IO is use-once, so probably not a caching problem at all.
> > 
> > This test case is specifically devised to confirm whether this patch
> > works as expected. Conclusion: it is.
> 
> Dejection ;-)
> 
> The number should address the patch is useful or not. confirming as expected
> is not so great.

OK, let's make the conclusion in this way:

The changelog analyzed the possible beneficial situation, and this
test backs that theory with real numbers, ie: it successfully stops
major faults when the active file list is slowly scanned when there
are partially cache hot streaming IO.

Another (amazing) finding of the test is, only around 1/10 mapped pages
are actively referenced in the absence of user activities.

Shall we protect the remaining 9/10 inactive ones? This is a question ;-)

Or, shall we take the "protect active VM_EXEC mapped pages" approach,
or Christoph's "protect all mapped pages all time, unless they grow
too large" attitude?  I still prefer the best effort VM_EXEC heuristics.

1) the partially cache hot streaming IO is far more likely to happen
   on (file) servers. For them, evicting the 9/10 inactive mapped
   pages over night should be acceptable for sysadms.

2) for use-once IO on desktop, we have Rik's active file list
   protection heuristics, so nothing to worry at all.

3) for big working set small memory desktop, the active list will
   still be scanned, in this situation, why not evict some of the
   inactive mapped pages? If they have not been accessed for 1 minute,
   they are not likely be the user focus, and the tight memory
   constraint can only afford to cache the user focused working set.

Does that make sense?
--
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/