On Fri, 21 Jun 2024 10:50:10 +0200 Michal Hocko <mhocko@xxxxxxxx> wrote: > On Thu 20-06-24 19:30:19, Oleg Nesterov wrote: > > Can't review, I forgot everything about mm_update_next_owner(). > > So I am sorry for the noise I am going to add, feel free to ignore. > > Just in case, I see nothing wrong in this patch. > > > > I think this deserves a comment to explain that this is optimization > > for the case we race with the pending mmput(). mm_update_next_owner() > > checks mm_users at the start. > > > > And. Can we drop tasklist and use rcu_read_lock() before for_each_process? > > Yes, this will probably need more changes even if possible... > > > > > > 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. I think this was alexjlzheng's first kernel contribution and as such we might not be hearing from him(?) again. And that's OK, thanks for the bug report - it helps Linux. Meanwhile we have a stalled patch in mm-unstable. If someone could add this issue to their todo list, that would be great.
