From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755830AbcDGJrZ (ORCPT ); Thu, 7 Apr 2016 05:47:25 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:34295 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755704AbcDGJrX (ORCPT ); Thu, 7 Apr 2016 05:47:23 -0400 Date: Thu, 7 Apr 2016 18:48:51 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Andrew Morton , Sergey Senozhatsky , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Byungchul Park , Sergey Senozhatsky Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async Message-ID: <20160407094851.GA1349@swordfish> References: <1459789048-1337-1-git-send-email-sergey.senozhatsky@gmail.com> <1459789048-1337-2-git-send-email-sergey.senozhatsky@gmail.com> <20160404155149.a3e3307def2d1315e2099c63@linux-foundation.org> <20160406082758.GA3554@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160406082758.GA3554@quack.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On (04/06/16 10:27), Jan Kara wrote: [..] > > Well, it's good that we have this. > > > > It would be better if it was runtime-controllable - changing boot > > parameters is a bit of a pain. In fact with this approach, your > > zillions-of-scsi-disks scenario becomes less problematic: do the async > > offloading during the boot process then switch back to the more > > reliable sync printing late in boot. > > Doing this should be relatively easy. It would be userspace's decision > whether they want more reliable or faster printk. Sounds fine with me. I can add it as a separate patch to the series. should be quite trivial. I have [minor] concerns, though. I can see how, for example, user space can decide what logging level it wants '1 4 4 7' or anything else, but how can user space decide what printk implementation it wants to use? I'm more or less positive not to back-port that `synchronous RW' patch to the kernels that I use; just because I don't want to give this freedom to people, sync printk is something I'm trying to run away from. > > This gets normal scheduling policy, so a spinning userspace SCHED_FIFO > > task will block printk for ever. This seems bad. > > I have to research this a bit but won't the SCHED_FIFO task that has > potentially unbounded amount of work lockup the CPU even though it does > occasional cond_resched()? depending on `watchdog_thresh' value, it can take something like 20+ seconds before watchdog will notice softlockup. so I'm setting printk kthread prio to `MAX_RT_PRIO - 1' as of now, just in case. I think I'll leave printk kthread init as a late_initcall. probably would prefer core/arch/device init calls to happen in sync printk mode. -ss