linux-kernel - Re: [patch] mm, compaction: add vmstats for kcompactd work

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]

Date:   Mon, 12 Dec 2016 14:20:06 -0800 (PST)
From:   David Rientjes <rientjes@...gle.com>
To:     Vlastimil Babka <vbabka@...e.cz>
cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] mm, compaction: add vmstats for kcompactd work

On Thu, 8 Dec 2016, Vlastimil Babka wrote:

> > A "compact_daemon_wake" vmstat exists that represents the number of times
> > kcompactd has woken up.  This doesn't represent how much work it actually
> > did, though.
> > 
> > It's useful to understand how much compaction work is being done by
> > kcompactd versus other methods such as direct compaction and explicitly
> > triggered per-node (or system) compaction.
> > 
> > This adds two new vmstats: "compact_daemon_migrate_scanned" and
> > "compact_daemon_free_scanned" to represent the number of pages kcompactd
> > has scanned as part of its migration scanner and freeing scanner,
> > respectively.
> > 
> > These values are still accounted for in the general
> > "compact_migrate_scanned" and "compact_free_scanned" for compatibility.
> > 
> > It could be argued that explicitly triggered compaction could also be
> > tracked separately, and that could be added if others find it useful.
> > 
> > Signed-off-by: David Rientjes <rientjes@...gle.com>
> 
> A bit of downside is that stats are only updated when compaction finishes, but
> I guess it's acceptable. Also I don't think the compact_control variables need
> the "total_" prefix, but no strong feelings. The explicit zero init should be
> also unnecessary.
> 

I actually prefer to have stats updated when compaction is finished for a 
single cycle, otherwise you get partially updated results: you have to 
make an inference of when a single compact_stall begins and ends.  If you 
need detailed data for a single invocation of compaction, tracepoints 
would be much better.

> Acked-by: Vlastimil Babka <vbabka@...e.cz>

Thanks!