Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20220113140318.11117-1-zhangliang5@huawei.com>
 <YeA5oP/iaxtVPHb3@casper.infradead.org> <CAHk-=wjB0i-B=U-DhpAajQx3f6bp1X==neLOrg0jwq29mgz=3g@mail.gmail.com>
 <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> <a93988da-80fb-dd32-4717-a6a0bae9e4ee@huawei.com>
 <dc415c4a-63aa-19b0-0fbc-795989970f6d@redhat.com> <fb02087a-b102-c91e-ab65-fb02cc8ee0a2@huawei.com>
 <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <b6df4f7f-c080-ad6c-d1ad-098115f016f3@huawei.com>
 <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> <Yel0BXVyj8uvsWJX@casper.infradead.org>
 <e2580cfa-a529-934d-861a-091c4a9714d4@redhat.com>
In-Reply-To: <e2580cfa-a529-934d-861a-091c4a9714d4@redhat.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 20 Jan 2022 17:37:11 +0200
Message-ID: <CAHk-=wjBFF_EJHVRe48jAjb7Xwu0aRNejyefzLOAGW_qnNu=-w@mail.gmail.com>
Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page
To:     David Hildenbrand <david@redhat.com>
Cc:     Matthew Wilcox <willy@infradead.org>,
        "zhangliang (AG)" <zhangliang5@huawei.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        wangzhigang17@huawei.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 20, 2022 at 5:26 PM David Hildenbrand <david@redhat.com> wrote:
>
> So your claim is that read-only, PTE mapped pages are weird? How do you
> come to that conclusion?
>
> If we adjust the THP reuse logic to split on additional references
> (page_count() == 1) -- similarly as suggested by Linus to fix the CVE --
> we're going to end up with exactly that more frequently.

If you write to a THP page that has page_count() elevated - presumably
because of a fork() - then that COW is exactly what you want to
happen.

And presumably you want it to happen page-by-page.

So I fail to see what the problem is.

The *normal* THP case is that there hasn't been a fork, and there is
no COW activity. That's the only thing worth trying to optimize for
and worry about.

If you do some kind of fork with huge-pages, and actually write to
those pages (as opposed to just execve() in the child and wait in the
parent), you only have yourself to blame. You *will* take COW faults,
and you have to do it, and at that point spliting the THP in whoever
did the COW is likely the right thing to do just to hope that you
don't have to allocate a whole new hugepage. So it will cause new
(small-page) allocations and copies.

And yes, at that point, writes to the THP page will cause COW's for
both sides as they both end up making that "split it" decision.

Honestly, would anything else ever even make sense?

If you care about THP performance, you make sure that the COW THP case
simply never happens.

                 Linus