Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Subject: Re: [PATCH 3/3] mm/uffd: Detect pgtable allocation failures
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <Y7cqMeTGSjsOPQ09@x1n>
Date:   Wed, 18 Jan 2023 13:51:30 -0800
Cc:     David Hildenbrand <david@redhat.com>,
        Linux-MM <linux-mm@kvack.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Muchun Song <songmuchun@bytedance.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        James Houghton <jthoughton@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <832F027A-3778-4670-BED6-1222FA905F13@gmail.com>
References: <20230104225207.1066932-1-peterx@redhat.com>
 <20230104225207.1066932-4-peterx@redhat.com>
 <AF984D5D-DC66-4FD3-A749-5AF6B7289E0D@gmail.com>
 <cc6e17ad-1afd-5c52-a06e-1d89d1978368@redhat.com>
 <B38AB79D-51D7-4F1A-A5CB-A60A46A3E27F@gmail.com> <Y7cqMeTGSjsOPQ09@x1n>
To:     Peter Xu <peterx@redhat.com>
Precedence: bulk

Sorry for the late response.

>> Yes, I propose it as an optional flag for UFFD-WP.
>> Anyhow, I believe the UFFD-WP as implemented now is not efficient and
>> should=E2=80=99ve been vectored to allow one TLB shootdown for many
>> non-consecutive pages.
>=20
> Agreed.  Would providing a vector of ranges help too for a few uffd =
ioctls?
>=20
> I'm also curious whether you're still actively developing (or running) =
your
> iouring series.

So I finished building a prototype some time ago, and one of the =
benefits
was in reducing memory reclamation time. Unfortunately, MGLRU then came =
and
took away a lot of the benefit.

A colleague of mine had a slightly different use-case, so I gave him the
code and he showed interest in upstreaming it. After some probing, it =
turns
out he decided he is not into the effort of upstreaming it. I can =
upstream
the vectored WP once I write some tests.
>>=20
>> I am not sure what the best way to detect that a page is write-pinned
>> reliably. My point was that if a change is already carried to
>> write-protect mechanisms, then this issue should be considered. =
Because
>> otherwise, many use-cases of uffd-wp would encounter implementation
>> issues.
>>=20
>> I will not =E2=80=9Ckill=E2=80=9D myself over it now, but I think it =
worth consideration.
>=20
> The current interface change is small and limited only to the extra =
-ENOMEM
> retval with memory pressures (personally I don't really know how to =
trigger
> this, as I never succeeded myself even with memory pressure..).  What =
you
> said does sound like a new area to explore, and I think it's fine to =
change
> the interface again.

Understood.

Thanks and sorry again for the late response,
Nadav=