From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754053AbdGCLL3 (ORCPT ); Mon, 3 Jul 2017 07:11:29 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:33040 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752035AbdGCLL1 (ORCPT ); Mon, 3 Jul 2017 07:11:27 -0400 Date: Mon, 3 Jul 2017 20:11:30 +0900 From: Sergey Senozhatsky To: Petr Mladek , Steven Rostedt Cc: Sergey Senozhatsky , Sergey Senozhatsky , Jan Kara , 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: <20170703111130.GA836@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> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170630133844.GD792@jagdpanzerIV.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 On (06/30/17 22:38), Sergey Senozhatsky wrote: > On (06/30/17 15:16), Petr Mladek wrote: > > Anyway, the handshake during offloading might be pretty > > problematic. To be honest, I do not have much experience > > with it. I have shared some my fears in the other mail[1]. > > Jan Kara spent a lot of time on this and probably could > > say more. > > > > Maybe, we could try to look into the throotling path. Slowing down > > massive printk() callers looks necessary when things gets > > out of control. > > throttling, in some form, is already there. I think. > > there is a printk_delay() function. which we can silently activate > when things don't look cool anymore. and printk_delay() is already > getting called on every vprintk_emit() entry. the question is -- how > big should be our delay value, and... when do we need to activate > printk_delay()? > > when the distance between console_seq and log_next_seq... suggests > that we will drop (overwrite) un-flushed messages sooner than console_seq > reaches log_next_seq? so log_next_seq is closer to log_first_seq than > console_seq to log_next_seq. something like below, may be. a sketch, just to demonstrate the idea. but, once polished, can go to printk out of series. ===8<===8<===8<=== Throttle printk() callers when we detect that consoles are far behind the logbuf: we printed to the consoles 4 times less messages than we still have to print. Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 38 ++++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index f24d3789faa0..fd546bd95207 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1758,17 +1758,43 @@ static void call_console_drivers(const char *ext_text, size_t ext_len, } } +#define PRINTK_FLOOD_DEFAULT_DELAY 10 + int printk_delay_msec __read_mostly; +static inline void __printk_delay(int m) +{ + while (m--) { + mdelay(1); + touch_nmi_watchdog(); + } +} + static inline void printk_delay(void) { - if (unlikely(printk_delay_msec)) { - int m = printk_delay_msec; + unsigned long flags; + u64 console_seen = 0, console_to_see; - while (m--) { - mdelay(1); - touch_nmi_watchdog(); - } + if (printk_delay_msec) { + __printk_delay(printk_delay_msec); + return; + } + + /* + * Check if consoles are far behind the loguf head and + * throttle printk() callers if so. + */ + logbuf_lock_irqsave(flags); + if (console_seq > log_first_seq) + console_seen = console_seq - log_first_seq; + console_to_see = log_next_seq - console_seq; + logbuf_unlock_irqrestore(flags); + + if (console_seen < 4 * console_to_see) { + if (printk_delay_msec) + __printk_delay(printk_delay_msec); + else + __printk_delay(PRINTK_FLOOD_DEFAULT_DELAY); } } -- 2.13.2