Re: [PATCH 5/5] mm: Insert some delay if ongoing memory allocation stalls.

[Michal Hocko <mhocko@suse.cz>]

On Sun 23-11-14 13:53:41, Tetsuo Handa wrote:
> >From 4fad86f7a653dbbaec3ba2389f74f97a6705a558 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Sun, 23 Nov 2014 13:41:24 +0900
> Subject: [PATCH 5/5] mm: Insert some delay if ongoing memory allocation stalls.
> 
> This patch introduces 1ms of unkillable sleep before retrying when
> sleepable __alloc_pages_nodemask() is taking more than 5 seconds.
> According to Documentation/timers/timers-howto.txt, msleep < 20ms
> can sleep for up to 20ms, but this should not be a problem because
> msleep(1) is called only when there is no choice but retrying.
> 
> This patch is intended for two purposes.
> 
> (1) Reduce CPU usage when memory allocation deadlock occurred, by
>     avoiding useless busy retry loop.
> 
> (2) Allow SysRq-w (or SysRq-t) to report how long each thread is
>     blocked for memory allocation.

Both do not make any sense to me whatsoever. If there is a deadlock then
we cannot consume CPU as the deadlocked tasks are _blocked_. I guess you
meant livelocked but even then, how does a random timeout helps?

Why would a timeout help sysrq to proceed?
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>