All of lore.kernel.org
 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 [PATCH] mm: vmscan: always allow writeback during memcg reclaim 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 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.