[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa5d7060-4e6e-16d5-2c37-fec6019b4d62@i-love.sakura.ne.jp>
Date: Sat, 14 Mar 2020 08:15:32 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: David Rientjes <rientjes@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems
On 2020/03/14 7:01, David Rientjes wrote:
> The entire issue is that the victim never gets a chance to run because the
> allocator doesn't give it a chance to run on an UP system. Your patch is
> broken because if the victim is current, you've lost your golden
> opportunity to actually exit and ceded control to the allocator that will
> now starve the victim.
>
I still cannot understand. There is no need to give CPU time to OOM victims.
We just need to give CPU time to the OOM reaper kernel thread till the OOM
reaper kernel thread sets MMF_OOM_SKIP to OOM victims. If current thread is
an OOM victim, schedule_timeout_killable(1) will give other threads (including
the OOM reaper kernel thread) CPU time to run. That is similar with your
cond_resched() patch (except that cond_resched() might fail to give other
threads CPU time to run if current thread has realtime priority), isn't it?
So, please explain the mechanism why cond_resched() works but
schedule_timeout_killable(1) cannot work.
Powered by blists - more mailing lists