Received-SPF: pass (google.com: domain of linux-kernel+bounces-91969-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240304103757.235352-1-21cnbao@gmail.com> <878r2x9ly3.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <CAGsJ_4yKhoztyA1cuSjGEeVwJfNdhNPNidrX-D_dRazRL7D5hg@mail.gmail.com> <6c16c7c5-8cf4-4c30-b3a5-a9ab55b21114@arm.com>
In-Reply-To: <6c16c7c5-8cf4-4c30-b3a5-a9ab55b21114@arm.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 5 Mar 2024 22:11:37 +1300
Message-ID: <CAGsJ_4w1dhqCu6UA4LGt9XDU_2jmcmWm1=E9MzX2tRv85NrLuw@mail.gmail.com>
Subject: Re: [RFC PATCH] mm: hold PTL from the first PTE while reclaiming a
 large folio
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: "Huang, Ying" <ying.huang@intel.com>, akpm@linux-foundation.org, linux-mm@kvack.org, 
	david@redhat.com, chrisl@kernel.org, yuzhao@google.com, hanchuanhua@oppo.com, 
	linux-kernel@vger.kernel.org, willy@infradead.org, xiang@kernel.org, 
	mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, 
	Barry Song <v-songbaohua@oppo.com>, Hugh Dickins <hughd@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 5, 2024 at 10:08=E2=80=AFPM Ryan Roberts <ryan.roberts@arm.com>=
 wrote:
>
> On 05/03/2024 08:56, Barry Song wrote:
> > are writing pte to zero(break) before writing a new value(make). while
>
> As an aside, "break-before-make" as defined in the Arm architecture would=
 also
> require a TLBI, which usually isn't done for these
> write-0-modify-prots-write-back operations. Arm doesn't require
> "break-before-make" in these situations so its legal (as long as only cer=
tain
> bits are changed). To my understanding purpose of doing this is to avoid =
races
> with HW access/dirty flag updates; if the MMU wants to set either flag an=
d finds
> the PTE is 0 (invalid) it will cause an exception which will be queued wa=
iting
> for the PTL.
>
> So I don't think you really mean break-before-make here.

I agree I use a stronger term. will change it to something lighter in v2.

>
> > this behavior is within PTL in another thread,  page_vma_mapped_walk()
> > of try_to_unmap_one thread won't take PTL till it meets a present PTE.
> > for example, if another threads are modifying nr_pages PTEs under PTL,
> > but we don't hold PTL, we might skip one or two PTEs at the beginning o=
f
> > a large folio.
> > For a large folio, after try_to_unmap_one(), we may result in PTE0 and =
PTE1
> > untouched but PTE2~nr_pages-1 are set to swap entries.
> >
> > by holding PTL from PTE0 for large folios, we won't get these intermedi=
ate
> > values. At the moment we get PTL, other threads have done.
>

Thanks
Barry