Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20230922193639.10158-1-vishal.moola@gmail.com>
 <20230922193639.10158-3-vishal.moola@gmail.com> <CAHbLzkqt8LFFDH2a7+xaQmncwiK=Ynv6vHs9d=TDNjp9_wJ4rw@mail.gmail.com>
 <ZRVB49PruFvT7+43@casper.infradead.org> <CAHbLzkqZHJV8j+C1czfDrZ9t8W_9YLDaZ7FnhNKa224ehnH1zA@mail.gmail.com>
In-Reply-To: <CAHbLzkqZHJV8j+C1czfDrZ9t8W_9YLDaZ7FnhNKa224ehnH1zA@mail.gmail.com>
From:   Vishal Moola <vishal.moola@gmail.com>
Date:   Mon, 2 Oct 2023 08:55:34 -0700
Message-ID: <CAOzc2pyqFZW8zwKKUdY4w-OOfac6t3VMNOrqXx751VDCuLGrCg@mail.gmail.com>
Subject: Re: [RFC PATCH 2/2] mm/khugepaged: Remove compound_pagelist
To:     Yang Shi <shy828301@gmail.com>
Cc:     Matthew Wilcox <willy@infradead.org>, linux-mm@kvack.org,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Sep 28, 2023 at 12:33=E2=80=AFPM Yang Shi <shy828301@gmail.com> wro=
te:
>
> On Thu, Sep 28, 2023 at 2:05=E2=80=AFAM Matthew Wilcox <willy@infradead.o=
rg> wrote:
> >
> > On Tue, Sep 26, 2023 at 03:07:18PM -0700, Yang Shi wrote:
> > > On Fri, Sep 22, 2023 at 9:33=E2=80=AFPM Vishal Moola (Oracle)
> > > <vishal.moola@gmail.com> wrote:
> > > >
> > > > Currently, khugepaged builds a compound_pagelist while scanning, wh=
ich
> > > > is used to properly account for compound pages. We can now account
> > > > for a compound page as a singular folio instead, so remove this lis=
t.
> > > >
> > > > Large folios are guaranteed to have consecutive ptes and addresses,=
 so
> > > > once the first pte of a large folio is found skip over the rest.
> > >
> > > The address space may just map a partial folio, for example, in the
> > > extreme case the HUGE_PMD size range may have HUGE_PMD_NR folios with
> > > mapping one subpage from each folio per PTE. So assuming the PTE
> > > mapped folio is mapped consecutively may be wrong.
> >
> > How?  You can do that with two VMAs, but this is limited to scanning
> > within a single VMA.  If we've COWed a large folio, we currently do
> > so as a single page folio, and I'm not seeing any demand to change that=
.
> > If we did COW as a large folio, we'd COW every page in that folio.
> > How do we interleave two large folios in the same VMA?
>
> It is not about COW. The magic from mremap() may cause some corner
> cases. For example,
>
> We have a 2M VMA, every 4K of the VMA may be mapped to a subpage from
> different folios. Like:
>
> 0: #0 subpage of folio #0
> 1: #1 subpage of folio #1
> 2: #2 subpage of folio #2
> ....
> 511: #511 subpage of folio #511
>
> When khugepaged is scanning the VMA, it may just isolate and lock the
> folio #0, but skip all other folios since it assumes the VMA is just
> mapped by folio #0.
>
> This may trigger kernel bug when unlocking other folios which are
> actually not locked and maybe data corruption since the other folios
> may go away under us (unisolated, unlocked and unpinned).

Thanks for the review. I did not know this could happen; I'll drop
this patch for
now until I can think of a better way to iterate through ptes for large fol=
ios.