Michal Hocko <mho...@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
