From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751025AbdEaHa5 (ORCPT ); Wed, 31 May 2017 03:30:57 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:35760 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbdEaHa4 (ORCPT ); Wed, 31 May 2017 03:30:56 -0400 Date: Wed, 31 May 2017 16:30:59 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Petr Mladek , Sergey Senozhatsky , 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: <20170531073058.GD7672@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170529121235.GG3608@quack2.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 Hello Jan, 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. > > First, the real time priority is questionable on its own. Logging > > is important but the real time priority is dangerous. Any "flood" > > of messages will starve all other processes with normal priority. > > It is better than a softlockup but it might cause problems as well. > > Processes with real-time priority should have well bounded runtime (in > miliseconds). Printk kthread doesn't have such bounded runtime so it should > not be a real time process as it could hog the CPU it is running on... yeah, I can easily make it a normal prio task. at the same time printk_kthread has 'soft' limits on its execution. it's under the same constraints as the rest of the processes that do printing. there can be a random RT task doing console_trylock()->console_unlock(), so we still can hog CPUs. but, yeah, I don't want printk_kthread to be special. > So I think what Petr suggests below is better. Keep normal priority, print > something to console from the process doing printk() and just wake up > printk kthread and hope it can print the rest. It is not ideal but unless > there's a flood of messages there is no regression to current state. hm, this is very close to what I do in my patch. with some additional guarantess. because people mostly want to have good old printk. that let's hope part basically doesn't work when it's needed the most. we had a ton of cases of lost messages in serial logs. I replied in more details in another mail. -ss