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@xxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>