From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753178AbcCGOnH (ORCPT ); Mon, 7 Mar 2016 09:43:07 -0500 Received: from mail-pf0-f182.google.com ([209.85.192.182]:35656 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752930AbcCGOm5 (ORCPT ); Mon, 7 Mar 2016 09:42:57 -0500 Date: Mon, 7 Mar 2016 23:40:51 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Sergey Senozhatsky , 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: <20160307144051.GB835@swordfish> References: <1457175338-1665-1-git-send-email-sergey.senozhatsky@gmail.com> <1457175338-1665-2-git-send-email-sergey.senozhatsky@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160307105248.GF5201@quack.suse.cz> 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 11:52), Jan Kara wrote: [..] > So for UP systems, we should by default disable async printing anyway I > suppose. It is just a pointless overhead. So please just make printk_sync > default to true if !CONFIG_SMP. ok, thanks. > When IRQs are disabled, you're right we will have a change in behavior. I > don't see an easy way of avoiding delaying of printk until IRQs get > enabled. I don't want to queue work directly because that creates > possibility for lock recursion in queue_work(). And playing some tricks > with irq_works isn't easy either - you cannot actually rely on any other > CPU doing anything (even a timer tick) because of NOHZ. yes. I thought about some sort of PRINTK_IPI on smp, and queue work from PRINTK_IPI. which is a bit insane. > So if this will be a problem in practice, using a kthread will probably be > the easiest solution. probably kthread is the way to go then. Tetsuo's bad experience with workqueues also sounds a bit alarming. I'll post a new patch soon. -ss