Sergey Senozhatsky wrote: > Hello, > > On (03/07/16 09:22), Jan Kara wrote: > [..] > > > hm, just for note, none of system-wide wqs seem to have a ->rescuer thread > > > (WQ_MEM_RECLAIM). > > > > > > [..] > > > > Even if you use printk_wq with WQ_MEM_RECLAIM for printing_work work > > > > item, > > > > printing_work_func() will not be called until current work item calls > > > > schedule_timeout_*(). That will be an undesirable random delay. If you > > > > use > > > > a dedicated kernel thread rather than a dedicated workqueue with > > > > WQ_MEM_RECLAIM, > > > > we can avoid this random delay. > > > > > > 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.
