linux-kernel - Re: [RFC 1/2] deactive invalidated pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20101124180122.GC19571@csn.ul.ie>
Date:	Wed, 24 Nov 2010 18:01:22 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ben Gamari <bgamari@...il.com>, linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Nick Piggin <npiggin@...nel.dk>
Subject: Re: [RFC 1/2] deactive invalidated pages

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/