Re: [PATCH 1/3] mm,oom: Move last second allocation to inside the OOM killer.

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

 



On Tue 05-12-17 23:07:53, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 05-12-17 22:17:27, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > > I do understand the upsides you're advocating for - although you
> > > > > haven't quantified them. They're just not worth the downsides.
> > > > 
> > > > OK, fair enough. Let's drop the patch then. There is no _strong_
> > > > justification for it and what I've seen as "nice to have" is indeed
> > > > really hard to quantify and not really worth merging without a full
> > > > consensus.
> > > 
> > > Dropping "mm,oom: move last second allocation to inside the OOM killer"
> > > means dropping "mm,oom: remove oom_lock serialization from the OOM reaper"
> > > together, right?
> > 
> > No, I believe that we can drop the lock even without this patch. This
> > will need more investigation though.
> 
> We cannot drop the lock without this patch.

This should be discussed in the respective thread.
 
> > > The latter patch helped mitigating
> > > schedule_timeout_killable(1) lockup problem though...
> > > 
> > > Also, what is the alternative for "mm,oom: use ALLOC_OOM for OOM victim's
> > > last second allocation" ? I proposed "mm, oom: task_will_free_mem(current)
> > > should ignore MMF_OOM_SKIP for once." and rejected by you. I also proposed
> > > "mm,oom: Set ->signal->oom_mm to all thread groups sharing the victim's mm."
> > > and rejected by you.
> > 
> > Yes, and so far I am not really sure we have to care all that much. I
> > haven't seen any real world workload actually hitting this condition.
> > 
> 
> Somebody will observe what Manish Jaggi observed. OOM with mlock()ed and/or
> MAP_SHARED is irrelevant. There is always possibility that the OOM reaper
> fails to reclaim memory due to mmap_sem contention (and results in extra
> OOM kills).

... and we will try to handle this with due diligence as soon as we see
those reports and see how serious they are.

-- 
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>



[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