From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754703AbcCJJyH (ORCPT ); Thu, 10 Mar 2016 04:54:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:53221 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754640AbcCJJxx (ORCPT ); Thu, 10 Mar 2016 04:53:53 -0500 Date: Thu, 10 Mar 2016 10:53:50 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Jan Kara , Tetsuo Handa , akpm@linux-foundation.org, jack@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: <20160310095350.GP10940@pathway.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.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2016-03-09 15:09:50, Sergey Senozhatsky wrote: > On (03/07/16 13:16), Jan Kara wrote: > 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(). I would sort this by priorities. I know about real-world problems that will get solved by async printk. I haven't heard yet people complaining about blocked console_lock()/console_unlock() calls outside printk code. So, I would personally prefer to handle async printk first. Heh, you opened an interesting can of worms. There are definitely locations that just want to manipulate the list of consoles and their setting without the need to push the date. I wonder how many locations really need to push the data. Note that console_unlock_for_printk() might be a bit misleading. Especially when you suggest to replace it by console_unlock() in vprintk_emit() ;-) I wonder if console_flush_and_unlock() might be more descriptive. We might even split flush_console() into a separate function in the end. I think that the combination with unlock() is there to make sure that somebody will flush the last messages from printk(), see the retry stuff. It probably won't be needed with the asynch printk(). Anyway, all these console_unlock() changes looks like another big step and I suggest to do it separately. I looking forward to see where this ends. Thanks, Petr PS: I want to check more precisely the async printk patchset but I am repeatedy sidetracked this week :-(