From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752237AbcCCL1O (ORCPT ); Thu, 3 Mar 2016 06:27:14 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:11887 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751183AbcCCL1M (ORCPT ); Thu, 3 Mar 2016 06:27:12 -0500 Subject: Re: [PATCH 1/3] printk: Make printk() completely async To: Jan Kara , Sergey Senozhatsky References: <1456934363-3199-1-git-send-email-jack@suse.cz> Cc: pmladek@suse.com, LKML From: Tetsuo Handa Message-ID: <56D81F7F.4010405@I-love.SAKURA.ne.jp> Date: Thu, 3 Mar 2016 20:26:55 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1456934363-3199-1-git-send-email-jack@suse.cz> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/03/03 0:59, Jan Kara wrote: > This patch makes printk() completely asynchronous (similar to what > printk_deferred() did until now). It appends message to the kernel > printk buffer and queues work to do the printing to console. This has > the advantage that printing always happens from a schedulable contex and > thus we don't lockup any particular CPU or even interrupts. Also it has > the advantage that printk() is fast and thus kernel booting is not > slowed down by slow serial console. Disadvantage of this method is that > in case of crash there is higher chance that important messages won't > appear in console output (we may need working scheduling to print > message to console). We somewhat mitigate this risk by switching printk > to the original method of immediate printing to console if oops is in > progress. Also for debugging purposes we provide printk.synchronous > kernel parameter which resorts to the original printk behavior. A few questions. (1) How do you handle PM/suspend? I think kernel threads including workqueue will be frozen during suspend operation. Maybe we can use an atomic_t counter (like oom_victims) which forces synchronous printing if counter value > 0. (2) Can we have a method for waiting for pending data to be flushed with timeout? If I want to emit as much messages as SysRq-t from schedulable context, I want to wait for flush before proceeding. This is different from using atomic_t counter suggested in (1), for asynchronous printk() helps reducing RCU duration; queuing to string buffer from RCU context and emitting from !RCU context will be preferable. (3) Is reliability of SysRq-t changed by this patch? I mean, does this patch make SysRq-t prone to drop traces if the logbuf was not large enough? (4) This will be outside of this proposal's scope, but it would be nice if we can selectively allow each console driver to control loglevel to emit. For example, send all kernel messages to serial console (console=ttyS0,115200n8) but send only critical messages to login console (console=tty0). I'm interested in logging via serial console and netconsole but not via login console. Since traces sent to login console is swept away soon, waiting for login console is wasteful. (5) This will be outside of this proposal's scope, but it would be nice if printk() can combine multiple logs and pass to console drivers. For example, logging via netconsole will become significantly faster if printk() can combine multiple logs up to ethernet packet's size. A single stack trace can likely be sent using one ethernet packet.