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 1BC383FD941 for ; Wed, 1 Jul 2026 09:51:02 +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=1782899464; cv=none; b=Sv+7p0DBbxxDcZkdbIiVJ0FI2usb6yXgL4S46Hd+DxfVx7VXuQeis9NXE0NV02DfXcA1rUo/MiUiH48xvAshKZEjFlZCQYpaO7vYWJ6alV1KeT6ZyX1TycQkiSQrWPZ3d3Yct/F8bezBHeA1VhtH5uqQza1LiUW3jsgpPP02VCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782899464; c=relaxed/simple; bh=iuawkAnpLzfQJgcmcudwsHtEeMLDWogbppZXqX9fUI8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cqTHV/3S2ItxyTyzWjSB2lCOEt040TWYGPacY8f9UEMJenqKwlZGVVUIb3x2M/qvB3yMaqGR8tCUdMAH6NVPp4NPXyBZUJiDQmFsS7otycmIRAbRn/E8gFSdApUGij4QIpuS6KJwEl9M+vB5QdCbHEqgMtCqPGb2tHWC0iwP/ec= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hLnWdoy8; 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="hLnWdoy8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF88C1F00A3D for ; Wed, 1 Jul 2026 09:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782899462; bh=Z2iTkH44zrjde5YjDVOVEaWsS9SPfrTjlzsfaFMLyYE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=hLnWdoy8c+T7td6KZ16EjiqEhhyYhjiA0hSqKxco5xCbdMUNn4OXUBj6VCmiZJQmX DkR3ywdWq6gxwYKTKPRcbmNxd7xMVMbMWObmX8Dn7efWj2ryt9B5VfTlVTXGtdx7iT rJE2SHC7S84E44g4AOI2plbZGv2fMX2USo3YvRQgiUQofvOQAJ4OBcwDRavLoN5lCu IkpapKTJfWWl8dyOE20lQlV8fR9QznAZ/khrOYh++qjQ/lMK7V93NfD9YbKAjf36vy 4/XDpACHAkU1mz6jPGBN1I5dVZhLrjj0PXDhMtLMuWIuXZcWXKF7My3yYI1kO6rYG5 DUyZnQGTxPfeg== Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-92e65e18969so32086585a.1 for ; Wed, 01 Jul 2026 02:51:02 -0700 (PDT) X-Forwarded-Encrypted: i=1; AFNElJ+WBHKrQyl07RFVX2snwchzp8W//0JqL96p+lBN1k349x+C0cXWvEfyO3g1j15nnJEbt92Nb/5jVHRba80=@vger.kernel.org X-Gm-Message-State: AOJu0YzjSxWZ4tHX7UNk/03xDqrnnN8djKWtzjSJq8HM3Jf3WiaLjer1 eDku2wL85Lxo4NkAOIiVCBqo0RF73RhZOzqQRbbXs4ktdU3nSUqtWxsk8oD/wq2bM3kV+Crzz2c hwH0gA1v7tl/LvYMK23UYNj2R2UWsZ1Q= X-Received: by 2002:a05:620a:8002:b0:92e:5949:3567 with SMTP id af79cd13be357-92e696e87f8mr698511785a.14.1782899462144; Wed, 01 Jul 2026 02:51:02 -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> <1e7a712b-33f4-44c2-85ed-6333ddca421c@kernel.org> <430e75bc-3993-40da-9996-71583e44c2d5@kernel.org> In-Reply-To: <430e75bc-3993-40da-9996-71583e44c2d5@kernel.org> From: Barry Song Date: Wed, 1 Jul 2026 17:50:51 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CfiVBuGxL7Vf8ra-H8elzsaPTNXC_3eQPhC59d80Jbf0OIbfH_V74Ph9c8 Message-ID: Subject: Re: [PATCH v2 4/4] mm: try to free swapcache for non-LRU folios To: "David Hildenbrand (Arm)" Cc: Kairui Song , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2026 at 4:18=E2=80=AFPM David Hildenbrand (Arm) wrote: [...] > > > > The newly allocated folio will likely still be sitting in this > > CPU's local LRU cache. If we drop the drain in patch 1, it seems > > there is little point in calling do_wp_page() from > > do_swap_page(), since we won't be able to reuse the folio while > > it remains in the local LRU cache. > > Well, we call do_wp_page() here to avoid another page fault where we woul= d end > up in do_wp_page() and actually break COW. Yep. We still need do_wp_page() to handle CoW, but we could actually reuse the folio if we don't drop the LRU drain. > > > > > So I'm wondering whether we should keep the drain in > > patch 1 by checking for a refcount of 3, or instead do > > something like the following in patch 4: > > > > > > if ((vmf->flags & FAULT_FLAG_WRITE) && !pte_write(pte)) { > > lru_add_drain(); > > ret |=3D do_wp_page(vmf); > > if (ret & VM_FAULT_ERROR) > > ret &=3D VM_FAULT_ERROR; > > } > > > > Otherwise, the combination of patches 1 and 4 seems somewhat > > inconsistent. It feels like a strange mix of sweet, spicy, > > hot, and cold=E2=80=94kind of contradictory :-) > > Yes, this needs a proper thought. > > What you describe is relevant for > > e.g., > > swapout > fork -> exclusive bit cleared > child exit -> parent is single user > swapin -> added to swapcache and LRU cache > > > This is not very odd, so we should keep that working (I think I have > micro-benchmarks for that). Maybe the simplest approach is to keep the drain in patch 1 and just make the code improvements you suggested in [1]? That way, we won't regress the potential reuse in do_swap_page(). [1] https://lore.kernel.org/all/c4718e32-2baa-4dee-873c-7ab99f21ca4e@kernel= .org/ Thanks Barry