From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752347AbdF2Hj7 (ORCPT ); Thu, 29 Jun 2017 03:39:59 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:36069 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751675AbdF2Hjw (ORCPT ); Thu, 29 Jun 2017 03:39:52 -0400 Date: Thu, 29 Jun 2017 16:40:00 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Jan Kara , Sergey Senozhatsky , Steven Rostedt , Andrew Morton , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Pavel Machek , Andreas Mohr , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Message-ID: <20170629074000.GA14897@jagdpanzerIV.localdomain> References: <20170509082859.854-1-sergey.senozhatsky@gmail.com> <20170509082859.854-3-sergey.senozhatsky@gmail.com> <20170510055935.GA1966@jagdpanzerIV.localdomain> <20170529092906.GD21894@pathway.suse.cz> <20170529121235.GG3608@quack2.suse.cz> <20170531073058.GD7672@jagdpanzerIV.localdomain> <20170601072102.GB3506@jagdpanzerIV.localdomain> <20170628131732.GP1538@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170628131732.GP1538@pathway.suse.cz> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (06/28/17 15:17), Petr Mladek wrote: > On Thu 2017-06-01 16:21:02, Sergey Senozhatsky wrote: > > On (05/31/17 16:30), Sergey Senozhatsky wrote: > > > On (05/29/17 14:12), Jan Kara wrote: > > > [..] > > > > Actually I had something very similar in old versions of my patch set. And > > > > it didn't work very well. The problem was that e.g. sometimes scheduler > > > > decided that printk kthread should run on the same CPU as the process > > > > currently doing printing and in such case printk kthread never took over > > > > printing and the machine locked up due to heavy printing. > > > > > > hm, interesting. > > > > that's a tricky problem to deal with. > > > > > > > > ... so may be we can have per-CPU printk kthreads then > > > > static DEFINE_PER_CPU(struct task_struct *, printk_kthread); > > > > > > SMP hotplug threads, to be precise, the same way as watchdog has it. and > > then during offloading we can wake_up any printk_kthread that is knowingly > > not from this-CPU, all of them, let them compete for the console_sem. > > > > just a quick idea. > > > > thoughts? > > I am not sure if this is worth the resources. It think that one > big win of workqueues was that it reduced the amount of running > per-CPU kthreads. There are systems with thousands of CPUs. > > I am a bit afraid to use workqueues for flushing consoles. > It would be another dependency and another risk. > > Otherwise, per-CPU kthreads/workqueues primary handle per-CPU > resources. But printk_kthread would handle consoles that > need to be serialized anyway. It sounds weird to have > per-CPU task just to increase the chance that it will > get scheduled. yeah. was just a quick idea. it has some 'interesting' options, tho. I'll reply in another thread. the waste of resources argument is somewhat interesting. I'm not arguing, and agree that per-CPU kthread for printk seems like a massive-massive overkill. the point is - I think that 99.999% of the time printk_safe and printk_nmi buffers are not needed. they simply waste memory. on a $BIG systems that's, once again, can be huge. so in terms of resources printk probably must do better, already. -ss