From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbcCJQ3H (ORCPT ); Thu, 10 Mar 2016 11:29:07 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:32924 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbcCJQ27 (ORCPT ); Thu, 10 Mar 2016 11:28:59 -0500 Date: Fri, 11 Mar 2016 01:26:49 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , 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: <20160310162649.GB567@swordfish> References: <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> <20160310095350.GP10940@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160310095350.GP10940@pathway.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/10/16 10:53), Petr Mladek wrote: [..] > 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 agree, let's settle down async printk() first. > 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. well, I see some problems with console_lock()/console_unlock() :) > 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. I've tested it briefly on some of the setups that I have around, and the boot time reduced by (very roughly) ~20+%; systemd and friends do a number of tty/etc. calls, and stuck in console_unock() each time. of course, the "pre-condition" here are printk()s from drivers/etc. (frequent enough to keep call_console_drivers() busy, not necessarily "pressure"). even on my laptop, userspace does a ton of console_unlock() ... [] console_unlock+0x24/0x89 [] console_device+0x4a/0x54 [] tty_open+0x127/0x4c5 [] chrdev_open+0x13f/0x164 [] ? cdev_put+0x23/0x23 [] do_dentry_open.isra.1+0x1b3/0x29e [] vfs_open+0x53/0x58 [] path_openat+0xa37/0xc8c [] do_filp_open+0x4d/0xa3 [] ? __alloc_fd+0x1ae/0x1c0 [] ? _raw_spin_unlock+0x27/0x31 [] do_sys_open+0x13c/0x1cc [] ? do_sys_open+0x13c/0x1cc [] SyS_open+0x1e/0x20 [] entry_SYSCALL_64_fastpath+0x18/0xa8 ____fput()->console_unlock() [] console_unlock+0x24/0x89 [] con_shutdown+0x2d/0x30 [] release_tty+0x52/0x12e [] tty_release+0x436/0x453 [] __fput+0x107/0x1ba [] ____fput+0xe/0x10 [] task_work_run+0x67/0x90 [] exit_to_usermode_loop+0x66/0x84 [] syscall_return_slowpath+0x8d/0x92 [] entry_SYSCALL_64_fastpath+0xa6/0xa8 ... etc. > 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. oh, yes, the function name was absolutely random. console_flush_and_unlock() looks good. > 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. ok. > PS: I want to check more precisely the async printk patchset but > I am repeatedy sidetracked this week :-( no prob! it's a pre-merge period, no pressure. I'll re-spin the printk() patch tomorrow, I think. async console_unlock() will be separated. -ss