On (03/07/16 20:10), Tetsuo Handa wrote: [..] > > > > hm. yes, seems that it may take some time until workqueue wakeup() a > > > > ->rescuer thread. > > > > need to look more. > > > > > > Yes, it takes some time (0.1s or 2 jiffies) before workqueue code gives up > > > creating a worker process and wakes up rescuer thread. However I don't see > > > that as a problem... > > > > yes, that's why I asked Tetsuo whether his concern was a wq's MAYDAY timer > > delay. the two commits that Tetsuo pointed at earlier in he loop > > (373ccbe59270 > > and 564e81a57f97) solved the problem by switching to WQ_MEM_RECLAIM wq. > > I've slightly tested OOM-kill on my desktop system and haven't spotted any > > printk delays (well, a test on desktop is not really representative, of > > course). > > I wanted to tell that if kworker is running a buggy function that calls > cond_resched() but does not call schedule_timeout_*() for very long time, > such delay can become many seconds. WQ_MEM_RECLAIM is a requirement for > waking up when kworker called schedule_timeout_*(). WQ_MEM_RECLAIM wq can > still cause huge delay if kworker does not call schedule_timeout_*(). > Not specific to OOM-killer or vmstat.
your point is taken. thanks. -ss