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 097561A3166 for ; Sat, 20 Jun 2026 08:10:22 +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=1781943024; cv=none; b=tLKukFGipUPYwkrVXH3NifWFhdRivFmQOj6Pz/D11Fr+Zrj1Qb20pjpuiydfoHPDHNYl7Dv/d0o+H2xxaw6/slDGFmxC94fchmDTYlYVT3PWI+Ded5I62GzNOfXX7fJLZJhoq0IeEu0h3jiUT/HrmExsR1/rsvJvHFbg3gMI5Jo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781943024; c=relaxed/simple; bh=C9OM0MgWHi0SDsm60rzcILqDhmJJE05nT8HcxhbPpSQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=XQ/D/JUMFEwfVslSZx+r2F9Q+bzMkVqxD4He4idwqgoDgwIT0DEhs0xYtKxYTt/RrUW39jvDFicaa8UEn9Ei0ylicZYY7lo9KfiEoEUYvkqb/G0ibOYOebXmpYp5ziE0aleI6HbJZK2pn1WYR2Awlns0CTdbjzZrhpTFI6tqfBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q9WITInZ; 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="Q9WITInZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4853C1F000E9; Sat, 20 Jun 2026 08:10:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781943022; bh=4gGw4YYhbCFNwv1pDJFddAqeyJBVIitz2x+M8cbi70A=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Q9WITInZ/lRLRcWN6643y3whNa/8lGpOMxgK0dxXNkfWZXjO/hOX/aYnn25UdZkG4 nWATsjgG32adk5ffvTaOGZmGFibhEHC7Q4Bccxd0UcQEGvZDjdFg/VTlPrrm9SZ+mK yOb5ztgqZA41yRR6dJmrKgXJbF6/p0EmKQj8xmw5wpRLQ+1qMjnu93V2NTdC/bNmMr J0LMB5xtwq8SzcbfbB8cgbVy8tN0+7a+V0Bep1YQZo81OMtxvFtWzTtv23itK9XGo1 cc7AM0HTN2EKBXfZh67dOY1n0iCMj4wgPBBtVQFlxliWoyqoaIieRJ07+oivjjJfsB MA4pBh0/KJpEw== From: "Barry Song (Xiaomi)" To: david@kernel.org Cc: akpm@linux-foundation.org, axelrasmussen@google.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, dev.jain@arm.com, kasong@tencent.com, lance.yang@linux.dev, liam@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, npache@redhat.com, qi.zheng@linux.dev, ryan.roberts@arm.com, shakeel.butt@linux.dev, weixugc@google.com, yuanchu@google.com, zhaonanzhe@xiaomi.com, ziy@nvidia.com Subject: Re: [RFC PATCH] mm: Avoiding split large folios if swap has no space Date: Sat, 20 Jun 2026 16:10:17 +0800 Message-Id: <20260620081017.89085-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <5790c4a4-d502-4180-82f5-47de5809a4fe@kernel.org> References: <5790c4a4-d502-4180-82f5-47de5809a4fe@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 Fri, Jun 19, 2026 at 10:04 PM David Hildenbrand (Arm) wrote: [...] > > /* > > * The page can not be swapped. > > * > > @@ -1280,6 +1289,8 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > > > > if (!folio_test_large(folio)) > > goto activate_locked_split; > > + if (!__can_reclaim_anon_pages(memcg, sc)) > > + goto activate_locked_split; > > Why are we even trying to allocate swap space if we cannot reclaim such pages? > Makes we wonder whether we would want to have that check earlier, before the > folio_alloc_swap(). > > Any downsides? I don't think there are any obvious downsides there. One issue is that the memcg may not be passed from reclaim_pages(), so memcg would always be NULL. However, the folio could still belong to a memcg whose swap quota has been exhausted. In that case, my __can_reclaim_anon_pages() will fail when checking whether we can swap out. But switching to folio_memcg() also seems awkward. So I feel Kairui’s suggestion [1] might be the best approach. In folio_alloc_swap(), we return -EAGAIN to tell vmscan.c that we can split the folio and retry the swap-out. only when there are sufficient swap slots and sufficient memcg swap quota do we return -EAGAIN, allowing vmscan to perform a split. diff --git a/mm/swapfile.c b/mm/swapfile.c index 78b49b0658ad..62e2c506ccae 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1755,6 +1755,9 @@ int folio_alloc_swap(struct folio *folio) VM_WARN_ON_ONCE(1); return -EINVAL; } + + if (get_nr_swap_pages() < (1 << order)) + return -ENOMEM; } again: @@ -1769,11 +1772,13 @@ int folio_alloc_swap(struct folio *folio) } /* Need to call this even if allocation failed, for MEMCG_SWAP_FAIL. */ - if (unlikely(mem_cgroup_try_charge_swap(folio))) + if (unlikely(mem_cgroup_try_charge_swap(folio))) { swap_cache_del_folio(folio); + return -ENOMEM; + } if (unlikely(!folio_test_swapcache(folio))) - return -ENOMEM; + return -EAGAIN; return 0; } diff --git a/mm/vmscan.c b/mm/vmscan.c index 299b5d9e8836..63e8578454ea 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1257,6 +1257,8 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, */ if (folio_test_anon(folio) && folio_test_swapbacked(folio) && !folio_test_swapcache(folio)) { + int ret; + if (!(sc->gfp_mask & __GFP_IO)) goto keep_locked; if (folio_maybe_dma_pinned(folio)) @@ -1275,10 +1277,10 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, split_folio_to_list(folio, folio_list)) goto activate_locked; } - if (folio_alloc_swap(folio)) { + if ((ret = folio_alloc_swap(folio))) { int __maybe_unused order = folio_order(folio); - if (!folio_test_large(folio)) + if (!folio_test_large(folio) || ret != -EAGAIN) goto activate_locked_split; /* Fallback to swap normal pages */ if (split_folio_to_list(folio, folio_list)) What’s your view on this, David? [1] https://lore.kernel.org/linux-mm/CAMgjq7Bmi2XYxPc4tVO8KTWSuj8jpt-c-JueqYRK1kLC_nmBqA@mail.gmail.com/ Best Regards Barry