[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240626152340.GA17644@redhat.com>
Date: Wed, 26 Jun 2024 17:23:40 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Michal Hocko <mhocko@...e.com>
Cc: alexjlzheng@...il.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
akpm@...ux-foundation.org, brauner@...nel.org, axboe@...nel.dk,
tandersen@...flix.com, willy@...radead.org, mjguzik@...il.com,
alexjlzheng@...cent.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH v2] mm: optimize the redundant loop of
mm_update_next_owner()
On 06/21, Michal Hocko wrote:
>
> On Thu 20-06-24 19:30:19, Oleg Nesterov wrote:
> >
> > Or even better. Can't we finally kill mm_update_next_owner() and turn the
> > ugly mm->owner into mm->mem_cgroup ?
>
> Yes, dropping the mm->owner should be a way to go. Replacing that by
> mem_cgroup sounds like an improvemnt. I have a vague recollection that
> this has some traps on the way. E.g. tasks sharing the mm but living in
> different cgroups. Things have changes since the last time I've checked
> and for example memcg charge migration on task move will be deprecated
> soon so chances are that there are less roadblocks on the way.
OK, thanks...
So if we can't do this right now, can we at least cleanup it? To me it looks
just ugly.
We don't need get/put_task_struct. The "retry" logic is obviously suboptimal.
The search in the children/siblings doesn't handle zombie leaders.
I'll send 2 (hopefully simple) patches in a minute, could you review? I have
no idea how to test them...
Oleg.
Powered by blists - more mailing lists