From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751927AbdGEQh5 (ORCPT ); Wed, 5 Jul 2017 12:37:57 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:36290 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751678AbdGEQhz (ORCPT ); Wed, 5 Jul 2017 12:37:55 -0400 Date: Thu, 6 Jul 2017 01:36:03 +0900 From: Sergey Senozhatsky To: Pavel Machek Cc: Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Andreas Mohr , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Message-ID: <20170705163603.GA488@tigerII.localdomain> References: <20170510055935.GA1966@jagdpanzerIV.localdomain> <20170529092906.GD21894@pathway.suse.cz> <20170531072233.GC7672@jagdpanzerIV.localdomain> <20170628121925.GN1538@pathway.suse.cz> <20170629073321.GA475@jagdpanzerIV.localdomain> <20170630070131.GA474@jagdpanzerIV.localdomain> <20170630131610.GT1538@pathway.suse.cz> <20170630133844.GD792@jagdpanzerIV.localdomain> <20170703111130.GA836@jagdpanzerIV.localdomain> <20170702202733.GB17293@xo-6d-61-c0.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170702202733.GB17293@xo-6d-61-c0.localdomain> 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, On (07/02/17 22:27), Pavel Machek wrote: [..] > > +#define PRINTK_FLOOD_DEFAULT_DELAY 10 > > + > > int printk_delay_msec __read_mostly; > > = 10; the idea is to throttle printk() only (and as long as) when we see that something is not right. like when we added 4 (a random number) times more messages that we were able to print so far. printk_delay_msec would throttle all printk calls. there is a difference. there are some cases that are sort of broken with this automatic throttling. the simples one is printk() under console_lock(). the harder one is throttling printk() from IRQ context. that can be risky, in theory. may be I'm overcomplicating here; if the system has hard locked up due to printk throttling from IRQ, then probably it was going to lockup anyway. need to check sysrq-t case, tho. > > + if (console_seen < 4 * console_to_see) { > > + if (printk_delay_msec) > > + __printk_delay(printk_delay_msec); > > + else > > + __printk_delay(PRINTK_FLOOD_DEFAULT_DELAY); > > And get rid of if () here? We want to enable delays of 0... this if () is totally useless and stupid, yes. realized after I sent the mail. -ss