From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 263E9332601 for ; Wed, 24 Jun 2026 21:14:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782335699; cv=none; b=PuGY8YyPSSIwIZTrscqSLcFWQbGmdQRex+CuOY8vUftSOuQjXRoFc6U4eprMnbPy599g+q6OdrUNa4wfPkIVK8+LYJTKUuVeJfzPvMrjPAAnjxV1wioWc1pm3piDCrP7yrtmMizlPa2natMDlXfxarov9hsmgdBRbHvzsYUmG3w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782335699; c=relaxed/simple; bh=VUTElLG0BZ8sZ59FLr4ICXRnxO5H1DcT+5MnHZM96Q8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WWlfCsto5fsKStIei83iLmrpeDce+7ceFuOxMt0RlQWALm1vdI8yrXhBQ0AHgGRW6o8q9kS3qyJRvPoUlaDKJ9c9/5ZEqibGuB0OKgAmw0ZTPGIC7whZXn7/MtzWoyw9ToG218PGke06d9dFjOGH6MmyHMwiZ7/WjTBuoibQ2Ps= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g78bl4l9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g78bl4l9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B81D11F00ADE for ; Wed, 24 Jun 2026 21:14:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782335697; bh=eCeZ8VqU84ruB94EwEJi8lpH01CxpMqlEj5VMxy+6kE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=g78bl4l94FFAYvnTYyk5UndiKA2HKHVuiWRjeSq0reQseTZMqOJJnDyaa52VAMXAH f3amUaMLJ38cXmbKd/amTF4m6eYpGbA0L4iNLy2VKur8C7Kswm3mACGQfXwdgCqzKH 9AAugfS8Cn23hFR5St6jXC/BqSCAneviHyPplYdDtNMv8+gTuUfUq7HK/tJDXNirk0 5tu8fK8wwhw7Oju0PuoKs+LKcabyaGYFVP75eLA7ffuo+9eMvBwogjx64yyFsAE8yl k9gHQW3KN0sfmYH6EmlwlrtWUq6y6yP+mOBwKSYpNQbPBRHoAyhAM2MhiRv5j73OYP 90NQqH5oyyAlg== Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-5178a42caa3so2641841cf.1 for ; Wed, 24 Jun 2026 14:14:57 -0700 (PDT) X-Forwarded-Encrypted: i=1; AFNElJ9H9xdB66TShiMv3aV8BLLBvYcfoMFT4r9f9qLlKezdxsHU3O0TbLS6+JCeEE2Mgx16bJaCg6ZX9ugG1OQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3aHpBtJi8FkevOXKDhWuI1AHfhyKn3Cu9ayOkk6002q4DjSHI FNmsYc3TmX3Q4cRuOUxaShHLVYfNkSIU6JjfVD31Wphka10/CvPY3/1hYVaIix5XlRilPcySqu1 oq1PfwYZITmxbOdZReG24LI3cZm083yk= X-Received: by 2002:ac8:5a48:0:b0:516:cd8d:c7fa with SMTP id d75a77b69052e-51a51be25demr128513661cf.39.1782335697092; Wed, 24 Jun 2026 14:14:57 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260623231635.43086-1-baohua@kernel.org> <20260623231635.43086-5-baohua@kernel.org> In-Reply-To: From: Barry Song Date: Thu, 25 Jun 2026 05:14:45 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CeWvGIPxeEZEtS2Z7zPM1_yMqbR3QHPGVgy4UGVB05PBeiFaRzILIH_fqE Message-ID: Subject: Re: [PATCH v2 4/4] mm: try to free swapcache for non-LRU folios To: "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, linux-mm@kvack.org, baoquan.he@linux.dev, chrisl@kernel.org, jp.kobryn@linux.dev, kasong@tencent.com, liam@infradead.org, linux-kernel@vger.kernel.org, ljs@kernel.org, mhocko@suse.com, nphamcs@gmail.com, rppt@kernel.org, shakeel.butt@linux.dev, shikemeng@huaweicloud.com, surenb@google.com, usama.arif@linux.dev, vbabka@kernel.org, youngjun.park@lge.com, Kairui Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2026 at 11:20=E2=80=AFPM David Hildenbrand (Arm) wrote: > > On 6/24/26 01:16, Barry Song (Xiaomi) wrote: > > Originally, we unconditionally called lru_add_drain() for write > > swap-in page faults. This might drop the reference held by the per-CPU > > LRU cache if the folio happened to reside there. However, there was no > > guarantee that the folio was actually cached on the current CPU. > > > > Now that lru_add_drain() has been removed, we have lost one > > opportunity to drop a reference held by the LRU cache. We could > > instead incorporate that possibility into the condition evaluated by > > should_try_to_free_swap(). > > > > Suggested-by: Kairui Song > > Signed-off-by: Barry Song (Xiaomi) > > --- > > mm/memory.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 2983a6baf474..14577c67c61a 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5087,8 +5087,11 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > * Remove the swap entry and conditionally try to free up the swa= pcache. > > * Do it after mapping, so raced page faults will likely see the = folio > > * in swap cache and wait on the folio lock. > > + * Assume non-LRU folios may be queued in the LRU cache, which co= ntributes > > + * an additional reference to the folio. > > */ > > - if (should_try_to_free_swap(si, folio, vma, nr_pages, vmf->flags)= ) > > + if (should_try_to_free_swap(si, folio, vma, nr_pages + > > + !folio_test_lru(folio), vmf->flags)) > > folio_free_swap(folio); > > > > folio_unlock(folio); > > Hm, in wp_can_reuse_anon_folio() we'll try dropping the swapcache ourselv= es. > > So I wonder if we still need that handling ("If we want to map a page tha= t's in > the swapcache writable, we ...") at all? > > > Ahh, I see the problem now: > > commit 4b34f1d82c6549837b2061096dea249e881a4495 > Author: Kairui Song > Date: Sat Dec 20 03:43:35 2025 +0800 > > mm, swap: free the swap cache after folio is mapped > > Currently, we remove the folio from the swap cache and free the swap = cache > before mapping the PTE. To reduce repeated faults due to parallel sw= apins > of the same PTE, change it to remove the folio from the swap cache af= ter > it is mapped. So new faults from the swap PTE will be much more like= ly to > see the folio in the swap cache and wait on it. > > This does not eliminate all swapin races: an ongoing swapin fault may > still see an empty swap cache. That's harmless, as the PTE is change= d > before the swap cache is cleared, so it will just return and not trig= ger > any repeated faults. This does help to reduce the chance. > > > That changed that behavior such that we *must* now always fallback to do_= wp_page(). > > What a mess (I didn't ack) So it seems we need a patch before patch 4 to fix the missed swapcache freeing on write faults, because the write bit has already been cleared by the time the folio is mapped and reused? diff --git a/mm/memory.c b/mm/memory.c index 14577c67c61a..e8fc5a86f6ea 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4752,6 +4752,7 @@ static void check_swap_exclusive(struct folio *folio, swp_entry_t entry, */ vm_fault_t do_swap_page(struct vm_fault *vmf) { + enum fault_flag fault_flags =3D vmf->flags; struct vm_area_struct *vma =3D vmf->vma; struct folio *swapcache =3D NULL, *folio; struct page *page; @@ -5091,7 +5092,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) * an additional reference to the folio. */ if (should_try_to_free_swap(si, folio, vma, nr_pages + - !folio_test_lru(folio), vmf->flags)) + !folio_test_lru(folio), fault_flags)) folio_free_swap(folio); folio_unlock(folio); Best Regards Barry