linux-kernel - Re: [PATCH 0/4] mm: Simplfy cow handling

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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 23 Aug 2020 19:58:24 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Maya B . Gokhale" <gokhale2@...l.gov>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Marty Mcfadden <mcfadden8@...l.gov>,
        Kirill Shutemov <kirill@...temov.name>,
        Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>,
        Jan Kara <jack@...e.cz>, Kirill Tkhai <ktkhai@...tuozzo.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/4] mm: Simplfy cow handling

On Sat, Aug 22, 2020 at 09:05:37AM -0700, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 4:50 PM Peter Xu <peterx@...hat.com> wrote:
> >
> >   - Run a busy loop dirty program [1] that uses 6G of memory, restrict to 1G
> >     RAM + 5G swap (cgroup).  A few hours later, all things still look good.
> >     Make sure to observe (still massive) correct page reuses using the new
> >     counter using the last patch, probably when swapping in.
> >
> >   - Run umapsort [2] to make sure uffd-wp will work again after applying this
> >     series upon master 5.9-rc1 (5.9-rc1 is broken).
> 
> I obviously like the diffstat, am wondering if you saw any throughput
> changes or similar for the busy-loop dirtying thing?

I didn't compare the two in my previous testing.

Firstly, although my program did output some dirty rate information in per
second basis, the dirty rate is kind of fluctuating during the runs due to
frequent swap in/out pages, and I cannot observe a stable dirty rate at least
with the patch applied.  I'm afraid I'll see similar thing even without
applying the patch. Maybe it'll show some statistic pattern if I do it per
10sec or longer, but not sure.

More importantly, I'm not sure whether that's the major case to compare either
if we want to have some rough understanding about patch 1 on the performance
impact.  The thing is, my test program only dirtied some private allocated
pages with itself as the only owner of the pages.  IIUC the page reuse logic
will trigger on either the old or new code because both the mapcount or
refcount will be one.  If we really want to compare the two, shouldn't we run
some tests that will trigger the COW differently before/after the patch?  E.g.,
when some pages are referenced by some GUP users and when COW happens with only
one pte mapped to the page.  I haven't thought deeper than this on such a test
yet.

So my previous testing was majorly for making sure the general cow and the swap
path will at least still behave as expected.

Thanks,

-- 
Peter Xu