[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJGiHyTXS_BqxoK2@tiehlicka>
Date: Tue, 5 Aug 2025 08:18:07 +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 14:01:40, Michal Hocko wrote:
> 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.
Btw. have you considered to simply not impose any delay for _all_ frozen
tasks?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists