From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752635AbcCGLKn (ORCPT ); Mon, 7 Mar 2016 06:10:43 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:22583 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752330AbcCGLKf (ORCPT ); Mon, 7 Mar 2016 06:10:35 -0500 To: sergey.senozhatsky.work@gmail.com Cc: 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 From: Tetsuo Handa References: <20160306093530.GA26055@swordfish> <201603062006.IJD17667.OOQFLtMVHOFSJF@I-love.SAKURA.ne.jp> <20160306132703.GA927@swordfish> <20160307082230.GB5201@quack.suse.cz> <20160307101233.GA10690@swordfish> In-Reply-To: <20160307101233.GA10690@swordfish> Message-Id: <201603072010.GDC69723.VFHMFOOSFtLJQO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 7 Mar 2016 20:10:19 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.