[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09d2d256-2eba-41ea-a397-dca4df5d5a2a@kernel.dk>
Date: Mon, 15 Dec 2025 19:23:07 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Johannes Weiner <hannes@...xchg.org>,
Christoph Hellwig <hch@...radead.org>
Cc: Deepanshu Kartikey <kartikey406@...il.com>, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: retiring laptop_mode? was Re: [PATCH] mm: vmscan: always allow
writeback during memcg reclaim
On 12/15/25 1:08 PM, Johannes Weiner wrote:
> On Sun, Dec 14, 2025 at 10:59:11PM -0800, Christoph Hellwig wrote:
>> On Sun, Dec 14, 2025 at 11:12:00PM -0500, Johannes Weiner wrote:
>>> 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).
>>
>> Yeah. I wonder if we should retire laptop_mode. It was a cute hack
>> back then, but it has it's ugly fingers in way to many places and
>> should be mostly obsolete by how writeback works these days.
>
> Yes, that makes sense to me. How about the below?
>
> It doesn't actually get rid of the reclaim toggles - I added comments
> for the other usecases. But it's a nice diffstat nonetheless.
>
> Debated whether to add some sort of deprecation sysctl handler, but at
> least systemd-sysctl just prints a warning and still applies other
> settings from the same config file.
>
> ---
>
> From 868f67e9d0d4465a6c22d8a147084944e7569c8d Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@...xchg.org>
> Date: Mon, 15 Dec 2025 12:57:53 -0500
> Subject: [PATCH] mm/block/fs: remove laptop_mode
>
> Laptop mode was introduced to save battery, by delaying and
> consolidating writes and maximize the time rotating hard drives
> wouldn't have to spin. Needless to say, this is a scenario of the
> (in)glorious past.
>
> The footprint of the feature is small, but nevertheless it's a
> complicating factor in mm, block, filesystems. Developers don't think
> about it, and the decision-making in reclaim looks dubious. It likely
> hasn't been tested in years while the surrounding code has evolved.
>From a quick glance, looks good to me:
Acked-by: Jens Axboe <axboe@...nel.dk>
--
Jens Axboe
Powered by blists - more mailing lists