[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250804115037.19690-1-zhongjinji@honor.com>
Date: Mon, 4 Aug 2025 19:50:37 +0800
From: zhongjinji <zhongjinji@...or.com>
To: <mhocko@...e.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>,
<zhongjinji@...or.com>
Subject: Re: [[PATCH v2] 2/2] futex: Only delay OOM reaper for processes using robust futex
>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.
Powered by blists - more mailing lists