Received-SPF: pass (google.com: domain of linux-kernel+bounces-132044-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240401202651.31440-1-vishal.moola@gmail.com>
 <20240401202651.31440-2-vishal.moola@gmail.com> <Zg6cualUqcsZYZxf@localhost.localdomain>
In-Reply-To: <Zg6cualUqcsZYZxf@localhost.localdomain>
From: Vishal Moola <vishal.moola@gmail.com>
Date: Thu, 4 Apr 2024 12:32:11 -0700
Message-ID: <CAOzc2pxfUSnT6fEXAJZowYeMz=hCgWsfJRB++dis1AL_rNScGQ@mail.gmail.com>
Subject: Re: [PATCH v2 1/3] hugetlb: Convert hugetlb_fault() to use struct vm_fault
To: Oscar Salvador <osalvador@suse.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
	akpm@linux-foundation.org, muchun.song@linux.dev, willy@infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2024 at 5:26=E2=80=AFAM Oscar Salvador <osalvador@suse.de> w=
rote:
>
> On Mon, Apr 01, 2024 at 01:26:49PM -0700, Vishal Moola (Oracle) wrote:
> > Now that hugetlb_fault() has a vm_fault available for fault tracking, u=
se
> > it throughout. This cleans up the code by removing 2 variables, and
> > prepares hugetlb_fault() to take in a struct vm_fault argument.
> >
> > Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
>
> Reviewed-by: Oscar Salvador <osalvador@suse.de>
>
> A question below:
>
> >  mm/hugetlb.c | 84 +++++++++++++++++++++++++---------------------------
> >  1 file changed, 41 insertions(+), 43 deletions(-)
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 8267e221ca5d..360b82374a89 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> ...
> >       /*
> > -      * entry could be a migration/hwpoison entry at this point, so th=
is
> > -      * check prevents the kernel from going below assuming that we ha=
ve
> > -      * an active hugepage in pagecache. This goto expects the 2nd pag=
e
> > -      * fault, and is_hugetlb_entry_(migration|hwpoisoned) check will
> > -      * properly handle it.
> > +      * vmf.orig_pte could be a migration/hwpoison vmf.orig_pte at thi=
s
>
> "vmf.orig_pte could be a migration/hwpoison entry at ..."
>
> > -     entry =3D pte_mkyoung(entry);
> > -     if (huge_ptep_set_access_flags(vma, haddr, ptep, entry,
> > +     vmf.orig_pte =3D pte_mkyoung(vmf.orig_pte);
> > +     if (huge_ptep_set_access_flags(vma, vmf.address, vmf.pte, vmf.ori=
g_pte,
> >                                               flags & FAULT_FLAG_WRITE)=
)
>
> Would it make sense to teach huge_ptep_set_access_flags/set_huge_pte_at()=
 to use
> vm_fault struct as well? All info we are passing is stored there.
> Maybe it is not worth the trouble though, just asking.

Yeah, it makes sense. There are actually many function calls in the
hugetlb_fault() and
__handle_mm_fault() pathways that could make use of vm_fault to clean
up the stack.

It's not particularly complicated either, aside from reorganizing some
variables for every
implementation of each function. I'm not really sure if it's worth
dedicated effort
and churn though (at least I'm not focused on that for now).