Re: [PATCH 1/2] mm,oom_reaper: Show trace of unable to reap victim thread.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michal Hocko wrote:
> On Tue 20-03-18 22:50:21, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 20-03-18 22:30:16, Tetsuo Handa wrote:
> > > > Michal Hocko wrote:
> > > > > On Tue 20-03-18 21:52:33, Tetsuo Handa wrote:
> > > > > > Michal Hocko wrote:
> > > > > > > A single stack trace in the changelog would be sufficient IMHO.
> > > > > > > Appart from that. What do you expect users will do about this trace?
> > > > > > > Sure they will see a path which holds mmap_sem, we will see a bug report
> > > > > > > but we can hardly do anything about that. We simply cannot drop the lock
> > > > > > > from that path in 99% of situations. So _why_ do we want to add more
> > > > > > > information to the log?
> > > > > > 
> > > > > > This case is blocked at i_mmap_lock_write().
> > > > > 
> > > > > But why does i_mmap_lock_write matter for oom_reaping. We are not
> > > > > touching hugetlb mappings. dup_mmap holds mmap_sem for write which is
> > > > > the most probable source of the backoff.
> > > > 
> > > > If i_mmap_lock_write can bail out upon SIGKILL, the OOM victim will be able to
> > > > release mmap_sem held for write, which helps the OOM reaper not to back off.
> > > 
> > > There are so many other blocking calls (including allocations) in
> > > dup_mmap 
> > 
> > Yes. But
> > 
> > >          that I do not really think i_mmap_lock_write is the biggest
> > > problem. That will be likely the case for other mmap_sem write lockers.
> > 
> > i_mmap_lock_write() is one of the problems which we could afford fixing.
> > 8 out of 11 "oom_reaper: unable to reap" messages are blocked at i_mmap_lock_write().
> > 
> [...]
> > > Really I am not sure dumping more information is beneficial here.
> > 
> > Converting to use killable where we can afford is beneficial.
> 
> 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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux