From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754651AbcCJJ1r (ORCPT ); Thu, 10 Mar 2016 04:27:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:50816 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754636AbcCJJ1a (ORCPT ); Thu, 10 Mar 2016 04:27:30 -0500 Date: Thu, 10 Mar 2016 10:27:49 +0100 From: Jan Kara To: Sergey Senozhatsky Cc: Jan Kara , Tetsuo Handa , 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: <20160310092749.GE5026@quack.suse.cz> References: <20160306063251.GA493@swordfish> <201603061618.GED43232.MtOQOFSLOFHJFV@I-love.SAKURA.ne.jp> <20160306093530.GA26055@swordfish> <201603062006.IJD17667.OOQFLtMVHOFSJF@I-love.SAKURA.ne.jp> <20160306132703.GA927@swordfish> <20160307082230.GB5201@quack.suse.cz> <20160307101233.GA10690@swordfish> <20160307105248.GF5201@quack.suse.cz> <20160307121625.GG5201@quack.suse.cz> <20160309060950.GA666@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160309060950.GA666@swordfish> 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 Wed 09-03-16 15:09:50, Sergey Senozhatsky wrote: > Hello Jan, > > On (03/07/16 13:16), Jan Kara wrote: > [..] > > > So if this will be a problem in practice, using a kthread will probably be > > > the easiest solution. > > > > Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues > > create kthread anyway as a rescuer thread, it may be the simplest to just > > go back to using a single kthread for printing. What do you think? > > I have this patch on top of the series now. In short, it closes one more > possibility of lockups -- console_lock()/console_unlock() calls. the patch > splits console_unlock() in two parts: > -- the fast one just wake up printing kthread > -- the slow one does call_console_drivers() loop > > I think it sort of makes sense to tweak the patch below a bit and fold it > into 0001, and move _some_ of the vprintk_emit() checks to console_unlock(). > > very schematically, after folding, vprintk_emit() will be > > if (in_sched) { > if (!printk_sync && printk_thread) > wake_up() > else > irq_work_queue() > } > > if (!in_sched) > if (console_trylock()) > console_unlock() > > and console_unlock() will be > > if (!in_panic && !printk_sync && printk_thread) { > up_console_sem() > wake_up() > } else { > console_unlock_for_printk() > } > > console_unlock_for_printk() does the call_console_drivers() loop. > > console_flush_on_panic() and printing_func() call console_unlock_for_printk() > directly. > > > What do you think? Or would you prefer to first introduce async > printk() rework, and move to console_unlock() in vprintk_emit() > one release cycle later? > IOW, in 3 steps: > -- first make printk() async > -- then console_unlock() async, and use console_unlock_for_printk() in > vprintk_emit() > -- then switch to console_unlock() in vprintk_emit(). > > > below is the patch which introduces console_unlock_for_printk(). > not the squashed console_unlock_for_printk() and 0001. So I think this should definitely stay as a separate patch since it possibly changes user visible behavior and sometimes blocking may be actually desirable for userspace. I don't have that strong opinion whether it should be in a separate patch set or part of this one. Maybe a separate patch set would be somewhat better so that we first hash out possible issues with async printk and once that's settled we start messing more with the code changing the behavior of console_unlock() as well. Honza -- Jan Kara SUSE Labs, CR