On Fri 02-06-17 20:13:32, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 01-06-17 22:11:13, Tetsuo Handa wrote: > >> Michal Hocko wrote: > >>> On Thu 01-06-17 20:43:47, Tetsuo Handa wrote: > >>>> Cong Wang has reported a lockup when running LTP memcg_stress test [1]. > >>> > >>> This seems to be on an old and not pristine kernel. Does it happen also > >>> on the vanilla up-to-date kernel? > >> > >> 4.9 is not an old kernel! It might be close to the kernel version which > >> enterprise distributions would choose for their next long term supported > >> version. > >> > >> And please stop saying "can you reproduce your problem with latest > >> linux-next (or at least latest linux)?" Not everybody can use the vanilla > >> up-to-date kernel! > > > > The changelog mentioned that the source of stalls is not clear so this > > might be out-of-tree patches doing something wrong and dump_stack > > showing up just because it is called often. This wouldn't be the first > > time I have seen something like that. I am not really keen on adding > > heavy lifting for something that is not clearly debugged and based on > > hand waving and speculations. > > You are asking users to prove that the problem is indeed in the MM subsystem, > but you are thinking that kmallocwd which helps users to check whether the > problem is indeed in the MM subsystem is not worth merging into mainline. > As a result, we have to try things based on what you think handwaving and > speculations. This is a catch-22. If you don't want handwaving/speculations, > please please do provide a mechanism for checking (a) and (b) shown later. configure watchdog to bug on soft lockup, take a crash dump, see what is going on there and you can draw a better picture of what is going on here. Seriously I am fed up with all the "let's do the async thing because it would tell much more" side discussions. You are trying to fix a soft lockup which alone is not a deadly condition. If the system is overwhelmed it can happen and if that is the case then we should care whether it gets resolved or it is a permanent livelock situation. If yes then we need to isolate which path is not preempting and why and place the cond_resched there. The page allocator contains preemption points, if we are lacking some for some pathological paths let's add them. For some reason you seem to be focused only on the warn_alloc path, though, while the real issue might be somewhere completely else. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
