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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 23 Aug 2020 20:24:11 -0400
From:   Peter Xu <>
To:     Linus Torvalds <>
Cc:     Linux-MM <>,
        Linux Kernel Mailing List <>,
        "Maya B . Gokhale" <>,
        Yang Shi <>,
        Marty Mcfadden <>,
        Kirill Shutemov <>,
        Oleg Nesterov <>, Jann Horn <>,
        Jan Kara <>, Kirill Tkhai <>,
        Andrea Arcangeli <>,
        Christoph Hellwig <>,
        Andrew Morton <>
Subject: Re: [PATCH 4/4] mm: Add PGREUSE counter

On Sat, Aug 22, 2020 at 09:14:53AM -0700, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 4:50 PM Peter Xu <> wrote:
> >
> > This accounts for wp_page_reuse() case, where we reused a page for COW.
> If we do this, wouldn't it make more sense to also count the COW case
> to see how they match up?

Is wp_page_reuse() only used in cow?

I saw that the callers of wp_page_reuse() are:

        (1) finish_mkwrite_fault
        (2) wp_pfn_shared
        (3) wp_page_shared
        (4) do_wp_page

Since (1) is only called by either (2) or (3), while (2) and (3) apply only to
shared memories, so I'm kind of sure the statistic is done via the changed path
in do_wp_page() that is touched in patch 1 (my program was using private
anonymous pages).  Maybe I missed something, though..

> Right now we count faults and major faults. So as a result you can can
> calculate minor faults trivially.
> But if you count page reuse, you can't calculate any stats on it,
> because most of the minor faults will presumably be for new pages
> (either zero or cached file mappings).
> So the "pgreuse" seems to be a counter without any context to it.
> IOW, I get the feeling that either we should do this properly (and
> maybe count "dirty faults" and "access" faults, at which point the
> reuse case becomes a subcase of the dirty ones) or we shouldn't do it
> at all. Creating a counter without any way to sanely compare it to
> anything seems a bit pointless.

Yeah I haven't thought deep about this statistic, imho it would be something
nice to have (besides helping me to verify the tests) so I still posted it
instead of keeping it in the local repo.  If this statistic is not liked by
anyone, then we can definitely drop it.


Peter Xu

Powered by blists - more mailing lists