Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 31 May 2018 20:07:28 -0500 | Subject | Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable |
| |
Michal Hocko <mhocko@kernel.org> writes:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote: >> This function searches for a new mm owner in children and siblings, >> and then iterates over all processes in the system in unlikely case. >> Despite the case is unlikely, its probability growths with the number >> of processes in the system. The time, spent on iterations, also growths. >> I regulary observe mm_update_next_owner() in crash dumps (not related >> to this function) of the nodes with many processes (20K+), so it looks >> like it's not so unlikely case. > > Did you manage to find the pattern that forces mm_update_next_owner to > slow paths? This really shouldn't trigger very often. If we can fallback > easily then I suspect that we should be better off reconsidering > mm->owner and try to come up with something more clever. I've had a > patch to remove owner few years back. It needed some work to finish but > maybe that would be a better than try to make non-scalable thing suck > less.
Reading through the code I just found a trivial pattern that triggers this. Create a multi-threaded process. Have the thread group leader (the first thread) exit.
This has the potential to be a significant DOS attack if anyone cares.
Eric
| |