Re: [RFC 1/2] deactive invalidated pages

[Mel Gorman]

On Wed, Nov 24, 2010 at 08:45:20AM +0900, Minchan Kim wrote:
> >
> >> I just don't see any argument for moving the page to the head of the
> >> inactive LRU as a matter of policy.  We can park it there because we
> >> can't think of anythnig else to do with it, but it's the wrong place
> >> for it.
> >>
> >
> > Is there a better alternative? One thing that springs to mind is that we are
> > not exactly tracking very well what effect these policy changes have. The
> > analysis scripts I have do a reasonable job on tracking reclaim activity
> > (although only as part of the mmtests tarball, I should split them out as
> > a standalone tool) but not the impact - namely minor and major faults. I
> > should sort that out so we can put better reclaim analysis in place.
> 
> It can help very much. :)
> 
> Also, I need time since I am so busy.
> 

No worries, I had a framework in place that made it easy enough to
collect. The necessary information is available in /proc/vmstat in this
case so a tester just needs to record vmstat before and after the target
workload runs. For the reclaim/compaction series, a partial run of the
series and the subsequent report looks like;

proc vmstat: Faults
                                       traceonly reclaimcompact obeysync
Major Faults                                 84102      6724      7298
Minor Faults                             139704394 138778777 138777304
Page ins                                   4966564   3621280   3569508
Page outs                                 11283328   7980576   7959352
Swap ins                                     85800      5647      7062
Swap outs                                   828488      8799     10565

Series acted as expected - major faults were reduced. Minor faults on on the
high side which I didn't analyse further. Main thing that it's possible to
collect the information on what reclaim is doing and how it affects processes.
I don't have anything in place to evaluate this series unfortunately as
I haven't automated a workload that depends on the behaviour of fadvise.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/