[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aJChI-LMwmuWEwpH@tiehlicka>
Date: Mon, 4 Aug 2025 14:01:39 +0200
From: Michal Hocko <mhocko@...e.com>
To: zhongjinji <zhongjinji@...or.com>
Cc: akpm@...ux-foundation.org, andrealmeid@...lia.com, dave@...olabs.net,
dvhart@...radead.org, feng.han@...or.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
liulu.liu@...or.com, mingo@...hat.com, npache@...hat.com,
peterz@...radead.org, rientjes@...gle.com, shakeel.butt@...ux.dev,
tglx@...utronix.de
Subject: Re: [[PATCH v2] 2/2] futex: Only delay OOM reaper for processes
using robust futex
On Mon 04-08-25 19:50:37, zhongjinji wrote:
> >On Fri 01-08-25 23:36:49, zhongjinji@...or.com wrote:
> >> From: zhongjinji <zhongjinji@...or.com>
> >>
> >> After merging the patch
> >> https://lore.kernel.org/all/20220414144042.677008-1-npache@redhat.com/T/#u,
> >> the OOM reaper runs less frequently because many processes exit within 2 seconds.
> >>
> >> However, when a process is killed, timely handling by the OOM reaper allows
> >> its memory to be freed faster.
> >>
> >> Since relatively few processes use robust futex, delaying the OOM reaper for
> >> all processes is undesirable, as many killed processes cannot release memory
> >> more quickly.
> >
> >Could you elaborate more about why this is really needed? OOM should be
> >a very slow path. Why do you care about this potential improvement in
> >that situation? In other words what is the usecase?
>
> Well, We are using the cgroup v1 freezer. When a frozen process is
> killed, it cannot exit immediately and is blocked in __refrigerator until
> it is thawed. When the process cannot be thawed in time, it will result in
> increased system memory pressure.
This is an important information to be part of the changelog! It is also
important to note why don't you care about processes that have robust
mutexes. Is this purely a probabilistic improvement because those are
less common?
TBH I find this to be really hackish and justification based on cgroup
v1 (which is considered legacy) doesn't make it particularly appealing.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists