From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751896AbdGEP7t (ORCPT ); Wed, 5 Jul 2017 11:59:49 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:35096 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbdGEP7r (ORCPT ); Wed, 5 Jul 2017 11:59:47 -0400 Date: Sun, 2 Jul 2017 22:27:33 +0200 From: Pavel Machek To: Sergey Senozhatsky Cc: 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: <20170702202733.GB17293@xo-6d-61-c0.localdomain> References: <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> <20170703111130.GA836@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170703111130.GA836@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2017-07-03 20:11:30, Sergey Senozhatsky wrote: > 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; = 10; > + 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... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html