From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753277AbcCGOib (ORCPT ); Mon, 7 Mar 2016 09:38:31 -0500 Received: from mail-pa0-f50.google.com ([209.85.220.50]:33247 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215AbcCGOiH (ORCPT ); Mon, 7 Mar 2016 09:38:07 -0500 Date: Mon, 7 Mar 2016 23:36:00 +0900 From: Sergey Senozhatsky To: Tetsuo Handa Cc: sergey.senozhatsky.work@gmail.com, akpm@linux-foundation.org, jack@suse.com, pmladek@suse.com, tj@kernel.org, linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async Message-ID: <20160307143600.GA835@swordfish> References: <20160306093530.GA26055@swordfish> <201603062006.IJD17667.OOQFLtMVHOFSJF@I-love.SAKURA.ne.jp> <20160306132703.GA927@swordfish> <20160307082230.GB5201@quack.suse.cz> <20160307101233.GA10690@swordfish> <201603072010.GDC69723.VFHMFOOSFtLJQO@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201603072010.GDC69723.VFHMFOOSFtLJQO@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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