On Tue, 20 Mar 2018, Tetsuo Handa wrote: > > I am no questioning that. I am questioning the additional information > > because we won't be able to do anything about mmap_sem holder most of > > the time. Because they tend block on allocations... > > serial-20180320.txt.xz is saying that they tend to block on i_mmap_lock_write() rather > than memory allocations. Making memory allocations killable will need a lot of work. > But I think that making frequently hitting down_write() killable won't need so much work. > I have available to me more than 28,222,058 occurrences of successful oom reaping and 13,018 occurrences of failing to grab mm->mmap_sem. The number of failures is low on production workloads, so I don't see an issue with emitting a stack trace in these instances if it can help improve things. But for my 0.04% failure rate, I can't say that I would look into them much unless it results in the system livelocking. Unless there's a compelling reason why this is shouldn't be done (too much email sent to linux-mm as a result? :), I say just go ahead and add the darn stack trace.
