All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosry@kernel.org>
To: Kairui Song <ryncsn@gmail.com>
Cc: Xueyuan Chen <xueyuan.chen21@gmail.com>,
	akpm@linux-foundation.org,  linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	 zhaonanzhe@xiaomi.com, baohua@kernel.org, hannes@cmpxchg.org,
	youngjun.park@lge.com,  baolin.wang@linux.alibaba.com,
	hughd@google.com, chrisl@kernel.org, kasong@tencent.com,
	 shikemeng@huaweicloud.com, nphamcs@gmail.com,
	baoquan.he@linux.dev, mhocko@kernel.org,
	 roman.gushchin@linux.dev, shakeel.butt@linux.dev,
	muchun.song@linux.dev, david@kernel.org,  ljs@kernel.org,
	liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,
	 surenb@google.com, qi.zheng@linux.dev, axelrasmussen@google.com,
	yuanchu@google.com,  weixugc@google.com
Subject: Re: [RFC PATCH v5 2/4] mm: distinguish large folio swap allocation failures
Date: Fri, 7 Aug 2026 20:11:41 +0000	[thread overview]
Message-ID: <anY7842WB7C308rX@google.com> (raw)
In-Reply-To: <anWAZ3T6Sz8bsKSo@KASONG-MC4>

On Fri, Aug 07, 2026 at 04:29:17PM +0800, Kairui Song wrote:
> On Thu, Jul 30, 2026 at 08:23:02PM +0800, Xueyuan Chen wrote:
> > folio_alloc_swap() reports most allocation failures with a generic
> > negative error code. Reclaim cannot tell whether splitting a large folio
> > could make progress or whether there is no backing space at all.
> > 
> > Keep the global free swap count and the remaining hierarchical memcg swap
> > margin as separate inputs. The memcg charge path reports only its own
> > margin; folio_alloc_swap() combines the two layers when classifying an
> > allocation failure.
> > 
> > Return -E2BIG for large folios when a smaller allocation might still fit,
> > -ENOSPC when no global swap space is available, and -ENOMEM when the
> > failure is not helped by splitting.
> > 
> > For early large-folio rejections, check global and memcg swap availability
> > instead of returning -E2BIG unconditionally. On a memcg charge failure,
> > swap slot allocation has already succeeded, so use the remaining memcg
> > margin to decide whether a smaller charge might fit.
> > 
> > This only refines folio_alloc_swap() return codes. The reclaim callers are
> > updated separately.
> > 
> > Suggested-by: Barry Song <baohua@kernel.org>
> > Suggested-by: Youngjun Park <youngjun.park@lge.com>
> > Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> >  include/linux/swap.h | 16 ++++++++++++----
> >  mm/memcontrol.c      | 32 +++++++++++++++++++++++++++++++-
> >  mm/swapfile.c        | 32 ++++++++++++++++++++++++--------
> >  3 files changed, 67 insertions(+), 13 deletions(-)
> > 
> 
> Hello Xueyuan,
> 
> Thanks for the patch!
> 
> > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > index 0544b2ec4c56..7d12058174ae 100644
> > --- a/include/linux/swap.h
> > +++ b/include/linux/swap.h
> > @@ -509,12 +509,13 @@ static inline void folio_throttle_swaprate(struct folio *folio, gfp_t gfp)
> >  #endif
> >  
> >  #if defined(CONFIG_MEMCG) && defined(CONFIG_SWAP)
> > -int __mem_cgroup_try_charge_swap(struct folio *folio);
> > -static inline int mem_cgroup_try_charge_swap(struct folio *folio)
> > +int __mem_cgroup_try_charge_swap(struct folio *folio, long *swap_margin);
> > +static inline int mem_cgroup_try_charge_swap(struct folio *folio,
> > +					     long *swap_margin)
> 
> Am I the only one that feel this returning argument is a bit ugly? See below..

No :)


  reply	other threads:[~2026-08-07 20:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 12:23 [RFC PATCH v5 0/4] mm: avoid large folio splits when swap is unavailable Xueyuan Chen
2026-07-30 12:23 ` [RFC PATCH v5 1/4] mm: add page_counter_margin() Xueyuan Chen
2026-08-06 13:51   ` David Hildenbrand (Arm)
2026-07-30 12:23 ` [RFC PATCH v5 2/4] mm: distinguish large folio swap allocation failures Xueyuan Chen
2026-08-06 13:56   ` David Hildenbrand (Arm)
2026-08-07  8:29   ` Kairui Song
2026-08-07 20:11     ` Yosry Ahmed [this message]
2026-08-07 21:06     ` Johannes Weiner
2026-08-07 23:10     ` Barry Song
2026-08-10  8:06     ` Xueyuan Chen
2026-08-07 23:12   ` Barry Song
2026-08-10 14:11     ` Xueyuan Chen
2026-07-30 12:23 ` [RFC PATCH v5 3/4] mm/vmscan: avoid pointless large folio splits without swap Xueyuan Chen
2026-08-06 13:58   ` David Hildenbrand (Arm)
2026-08-07 23:24     ` Barry Song
2026-08-07  2:03   ` Baolin Wang
2026-07-30 12:23 ` [RFC PATCH v5 4/4] mm/shmem: split large folios only on -E2BIG Xueyuan Chen
2026-08-06 13:59   ` David Hildenbrand (Arm)
2026-08-07 23:26   ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anY7842WB7C308rX@google.com \
    --to=yosry@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=baoquan.he@linux.dev \
    --cc=cgroups@vger.kernel.org \
    --cc=chrisl@kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kasong@tencent.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=nphamcs@gmail.com \
    --cc=qi.zheng@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --cc=ryncsn@gmail.com \
    --cc=shakeel.butt@linux.dev \
    --cc=shikemeng@huaweicloud.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=xueyuan.chen21@gmail.com \
    --cc=youngjun.park@lge.com \
    --cc=yuanchu@google.com \
    --cc=zhaonanzhe@xiaomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.