Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/24/26 00:36, Suren Baghdasaryan wrote:
> On Thu, Apr 23, 2026 at 2:50 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 4/23/26 09:50, Michal Hocko wrote:
>>> [...]
>>>
>>> This is a very creative/disruptive way to do a memory reclaim. From a
>>> user POV I would much rather see clean page cache reclaimed before my
>>> apps start to disappear. But this is obviously your call and your users
>>> that will care.
>>>
>>> Anyway, I still maintain my position. I do not think it is a good
>>> idea to drop clean page cache as you do not know whether there are other
>>> users.
> 
> I'm very much familiar with these issues in Android and really want to
> find a good solution for them. IIUC, this RFC tries to address 2
> things at once:
> 1. handling clean private page cache when reaping memory of a kill victim;
> 2. addressing a race between kill() and process_release() when
> process_release() can't happen before the kill() but if it happens too
> late after the victim passed its exit_mm() then process_release()
> fails to find the mm to reap. This defeats the purpose of
> process_release() call because the actual memory (released by
> exit_mmap()) might not yet be free and a successful process_release()
> would be very beneficial.
> 
> I see these two as separate issues and I'm not sure combining them
> into a single discussion is a good idea.
> 
>>
>> IIRC, Johannes raised in the past the we cannot predict the future.
>>
>> For example, if an app gets OOM-killed, wouldn't we usually try restarting it,
>> re-consuming the clean pagecache pages we would be evicting here?
> 
> Sure, we can't predict which app the user will use next, so when
> killing we usually kill the least recently used one. That's a
> reasonable strategy in most cases.

That makes sense. As long as other apps you open next won't need the same
libraries etc that you just evicted.

-- 
Cheers,

David