Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-16 Thread Michal Hocko
On Tue 16-02-16 20:11:24, Tetsuo Handa wrote: > Michal Hocko wrote: > > Unless we are under global OOM then this doesn't matter much because the > > allocation request should succeed at some point in time and memcg > > charges are bypassed for tasks with pending fatal signals. So we can > > make a

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-16 Thread Tetsuo Handa
Michal Hocko wrote: > Unless we are under global OOM then this doesn't matter much because the > allocation request should succeed at some point in time and memcg > charges are bypassed for tasks with pending fatal signals. So we can > make a forward progress. Hmm, then I wonder how memcg OOM live

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-15 Thread Michal Hocko
On Sun 07-02-16 00:33:38, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sat 06-02-16 14:54:24, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > > But if we consider non system-wide OOM events, it is not very > > > > > unlikely to hit > > > > > this race. This queue is useful for situations

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-06 Thread Tetsuo Handa
Michal Hocko wrote: > On Sat 06-02-16 14:54:24, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > > But if we consider non system-wide OOM events, it is not very unlikely > > > > to hit > > > > this race. This queue is useful for situations where memcg1 and memcg2 > > > > hit > > > > memcg OOM at

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-06 Thread Michal Hocko
On Sat 06-02-16 14:54:24, Tetsuo Handa wrote: > Michal Hocko wrote: > > > But if we consider non system-wide OOM events, it is not very unlikely to > > > hit > > > this race. This queue is useful for situations where memcg1 and memcg2 hit > > > memcg OOM at the same time and victim1 in memcg1 cann

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-05 Thread Tetsuo Handa
Michal Hocko wrote: > > But if we consider non system-wide OOM events, it is not very unlikely to > > hit > > this race. This queue is useful for situations where memcg1 and memcg2 hit > > memcg OOM at the same time and victim1 in memcg1 cannot terminate > > immediately. > > This can happen of c

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-04 Thread Michal Hocko
On Thu 04-02-16 19:49:29, Tetsuo Handa wrote: [...] > I think we want to rewrite this patch's description from a different point > of view. > > As of "[PATCH 1/5] mm, oom: introduce oom reaper", we assumed that we try to > manage OOM livelock caused by system-wide OOM events using the OOM reaper.

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-04 Thread Tetsuo Handa
Michal Hocko wrote: > From: Michal Hocko > > wake_oom_reaper has allowed only 1 oom victim to be queued. The main > reason for that was the simplicity as other solutions would require > some way of queuing. The current approach is racy and that was deemed > sufficient as the oom_reaper is conside

[PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

2016-02-03 Thread Michal Hocko
From: Michal Hocko wake_oom_reaper has allowed only 1 oom victim to be queued. The main reason for that was the simplicity as other solutions would require some way of queuing. The current approach is racy and that was deemed sufficient as the oom_reaper is considered a best effort approach to he