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 6850D3B71B1 for ; Wed, 29 Jul 2026 22:26:56 +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=1785364017; cv=none; b=RsjIUQKzNYJLXQIviN2Pepq4CNd9cUYcV74ttq8ngl4Kv4nFeFGDSm7y0jJG2Luw5pmum75spyH4FDEFhmG3VLZuzBZ0Bp+AwkmrUUpTyXgZrM8LvbQgGGDl3byOPs1iRWR7kDHqME8e2PIeXmUZDYGqnXbeaWp/vQ+FmOocPpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785364017; c=relaxed/simple; bh=WXgaulBSP4Xc8+9n0G1xXLn31zmR8ebfHmhHwAWRoPk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=R0/zXywKL/SiMW3StgsN/T+Wd73wtXkDiMqRyjgDh89ppPliykfnvuNX5JiD0CIxr2CN6W1GFn1DdzH/iLcLvCdLRG5yO5WHUtSVfO3d1+swGYohhQwY8N66HZxqNxF1wEshz4vGU5Np6dQX/Ho8niJ5IwlSEIYFPul9uhzjsN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dzIeNJxS; 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="dzIeNJxS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14FD41F000E9; Wed, 29 Jul 2026 22:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785364016; bh=5MIIT9QahtjXyg3K5yJSBOlaChmM2DGjfHykMVmRrdU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dzIeNJxSiYMJZi5moMkBeoDikkPefLAKWRKIkswjs/I3BM7cwAFB6skBxN+HC/Afe ww9zIxS9LLQ4YpRutQRIbWdmRH2iCX90ic/T8EtxtRfB8wv9RYtIAlXFutZC2J1of/ XAbVMf1eRe4lHa6uGBxa8bnqcvb2G5Z9AIViuU/XoJC6kIO74m/K/hMqP6WEzl+jVx fb5PLnrjUl4+NuOMPa2f+JG8U1wrnRYIlsBmixgm9pt/t7PBNMM08TjkVaUhc3K4eW XJGCwgC8+gTZXX/krkbZQZsHzFUoRFPSh1ZKY9/i5EeVSHJqexlv0teH2C809KeYSJ 21AzrBDn1ONbg== From: "Barry Song (Xiaomi)" To: david@kernel.org Cc: akpm@linux-foundation.org, baohua@kernel.org, baolin.wang@linux.alibaba.com, dev.jain@arm.com, lance.yang@linux.dev, liam@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, mhocko@suse.com, npache@redhat.com, rppt@kernel.org, ryan.roberts@arm.com, surenb@google.com, vbabka@kernel.org, ziy@nvidia.com Subject: Re: [RFC PATCH v2 1/2] mm: allow smaller large folios to use lru_cache Date: Thu, 30 Jul 2026 06:26:51 +0800 Message-Id: <20260729222651.31321-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <229c3079-8fde-41b4-9d6c-f0e34f780555@kernel.org> References: <229c3079-8fde-41b4-9d6c-f0e34f780555@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Wed, Jul 29, 2026 at 8:13 PM David Hildenbrand (Arm) wrote: [...] > > diff --git a/include/linux/swap.h b/include/linux/swap.h > > index 8d19be675baf..9c5f7a11c7b0 100644 > > --- a/include/linux/swap.h > > +++ b/include/linux/swap.h > > @@ -316,9 +316,9 @@ static inline bool folio_may_be_lru_cached(struct folio *folio) > > /* > > * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting. > > * Holding small numbers of low-order mTHP folios in per-CPU LRU cache > > - * will be sensible, but nobody has implemented and tested that yet. > > + * will be sensible. > > */ > > - return !folio_test_large(folio); > > + return folio_order(folio) < PAGE_ALLOC_COSTLY_ORDER; > > } > > > > extern atomic_t lru_disable_count; > > Sashiko rightfully raises that split_folio() can now fail more easily. > > So we might want to proactively drain (earlier?) on some more of the split paths. Yes, this is a pain. I haven't tested it, but perhaps a conceptual model could be something like this? diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 04e8a6b55343..fcd449dec96b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -4069,6 +4069,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order, struct folio *new_folio, *next; int nr_shmem_dropped = 0; enum ttu_flags ttu_flags = 0; + bool maybe_in_lru_cache; + int expected_ref_count; int ret; pgoff_t end = 0; @@ -4154,7 +4156,15 @@ static int __folio_split(struct folio *folio, unsigned int new_order, * Racy check if we can split the page, before unmap_folio() will * split PMDs */ - if (folio_expected_ref_count(folio) != folio_ref_count(folio) - 1) { + maybe_in_lru_cache = folio_may_be_lru_cached(folio) && !folio_test_lru(folio); + expected_ref_count = folio_expected_ref_count(folio); + if (expected_ref_count + maybe_in_lru_cache < folio_ref_count(folio) - 1) { + ret = -EAGAIN; + goto out_unlock; + } + if (maybe_in_lru_cache) + lru_add_drain_all(); + if (expected_ref_count != folio_ref_count(folio) - 1) { ret = -EAGAIN; goto out_unlock; } Best Regards Barry