linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Deepanshu Kartikey <kartikey406@gmail.com>,
	akpm@linux-foundation.org, axelrasmussen@google.com,
	yuanchu@google.com, weixugc@google.com, david@kernel.org,
	zhengqi.arch@bytedance.com, shakeel.butt@linux.dev,
	lorenzo.stoakes@oracle.com, yuzhao@google.com,
	heftig@archlinux.org, oleksandr@natalenko.name,
	bgeffon@google.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	syzbot+90fcab4d88cffed6d0d8@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm: vmscan: always allow writeback during memcg reclaim
Date: Mon, 15 Dec 2025 18:49:56 +0100	[thread overview]
Message-ID: <aUBKRDkIqlisJzF-@tiehlicka> (raw)
In-Reply-To: <20251215041200.GB905277@cmpxchg.org>

On Sun 14-12-25 23:12:00, Johannes Weiner wrote:
> On Sat, Dec 13, 2025 at 02:06:39PM +0530, Deepanshu Kartikey wrote:
> > When laptop_mode is enabled, may_writepage is set to 0 in
> > try_to_free_mem_cgroup_pages(). This triggers a warning in MGLRU's
> > lru_gen_shrink_lruvec():
> > 
> >     VM_WARN_ON_ONCE(!sc->may_writepage || !sc->may_unmap);
> > 
> > The warning occurs because MGLRU expects full reclaim capabilities to
> > function correctly. The call path is:
> > 
> >     mem_cgroup_resize_max()
> >       try_to_free_mem_cgroup_pages()
> >         do_try_to_free_pages()
> >           shrink_node()
> >             shrink_lruvec()
> >               lru_gen_shrink_lruvec()  <-- WARNING
> > 
> > Unlike kswapd or direct reclaim where laptop_mode's disk-saving behavior
> > is a reasonable optimization, memcg limit enforcement is a hard
> > requirement - memory MUST be freed when a cgroup exceeds its limit.
> 
> That reasoning doesn't make sense to me. Reclaim is always in response
> to an allocation need. The laptop_mode idea applies to cgroup reclaim
> as much as any other reclaim.
> 
> Now obviously all of this is pretty dated. Reclaim doesn't do
> filesystem writes anymore, and I'm not sure there are a whole lot of
> laptops with rotational drives left, either. Also I doubt anybody is
> still using zone_reclaim_mode (which is where the may_unmap is from).
> 
> But let's not introduce more inconsistencies, please. The only thing
> weird here is the MGLRU warning. What is it trying to assert? Clearly
> whatever assumption was made here has never been true.

Completely agreed. This patch seems to just paper over a warning that
seems dubious while doing something that doesn't make much sense in
itself. Dropping laptop_mode from the memory reclaim seems like the
right direction anyway. I seriously doubt that it makes any practical or
measurable difference even on slow rotating storage laptops these days.

-- 
Michal Hocko
SUSE Labs


      parent reply	other threads:[~2025-12-15 17:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-13  8:36 Deepanshu Kartikey
2025-12-14 23:49 ` Andrew Morton
2025-12-15  4:12 ` Johannes Weiner
2025-12-15  4:51   ` Deepanshu Kartikey
2025-12-15 19:42     ` Yuanchu Xie
2025-12-15 20:22       ` Johannes Weiner
2025-12-19  5:13       ` Kairui Song
2025-12-15  6:59   ` retiring laptop_mode? was " Christoph Hellwig
2025-12-15 16:33     ` Jens Axboe
2025-12-15 20:08     ` Johannes Weiner
2025-12-16  2:23       ` Jens Axboe
2025-12-16  7:41       ` Christoph Hellwig
2025-12-16 18:52         ` Johannes Weiner
2025-12-16 18:54           ` Jens Axboe
2025-12-16 23:23           ` Shakeel Butt
2025-12-17 19:59             ` Johannes Weiner
2025-12-18  7:21               ` Shakeel Butt
2025-12-17 19:34           ` Michal Hocko
2025-12-18  6:00           ` Christoph Hellwig
2025-12-15 17:49   ` Michal Hocko [this message]

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=aUBKRDkIqlisJzF-@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=bgeffon@google.com \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=heftig@archlinux.org \
    --cc=kartikey406@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=oleksandr@natalenko.name \
    --cc=shakeel.butt@linux.dev \
    --cc=syzbot+90fcab4d88cffed6d0d8@syzkaller.appspotmail.com \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=yuzhao@google.com \
    --cc=zhengqi.arch@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox