All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Eric Biederman <ebiederm@xmission.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, Pavel Machek <pavel@ucw.cz>,
	Andreas Mohr <andi@lisas.de>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread
Date: Mon, 3 Jul 2017 20:11:30 +0900	[thread overview]
Message-ID: <20170703111130.GA836@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <20170630133844.GD792@jagdpanzerIV.localdomain>

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 <sergey.senozhatsky@gmail.com>
---
 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

  reply	other threads:[~2017-07-03 11:11 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-09  8:28 [RFC][PATCHv3 0/5] printk: introduce printing kernel thread Sergey Senozhatsky
2017-05-09  8:28 ` [RFC][PATCHv3 1/5] printk: move printk_pending out of per-cpu Sergey Senozhatsky
2017-05-25 12:11   ` Petr Mladek
2017-05-25 12:36     ` Sergey Senozhatsky
2017-05-25 12:43       ` Petr Mladek
2017-05-09  8:28 ` [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky
2017-05-10  5:59   ` Sergey Senozhatsky
2017-05-29  9:29     ` Petr Mladek
2017-05-29 12:12       ` Jan Kara
2017-05-31  7:30         ` Sergey Senozhatsky
2017-05-31 21:44           ` Andreas Mohr
2017-06-01  7:21           ` Sergey Senozhatsky
2017-06-01  7:23             ` Sergey Senozhatsky
2017-06-01  9:20             ` Sergey Senozhatsky
2017-06-28 13:17             ` Petr Mladek
2017-06-29  7:40               ` Sergey Senozhatsky
2017-06-28 12:45           ` Petr Mladek
2017-05-31  7:22       ` Sergey Senozhatsky
2017-06-28 12:19         ` Petr Mladek
2017-06-29  6:26           ` Andreas Mohr
2017-06-29  7:00             ` Andreas Mohr
2017-06-29  7:33           ` Sergey Senozhatsky
2017-06-29 11:24             ` Tetsuo Handa
2017-06-30  7:01             ` Sergey Senozhatsky
2017-06-30 10:18               ` Tetsuo Handa
2017-06-30 11:57                 ` Sergey Senozhatsky
2017-06-30 12:35                   ` Tetsuo Handa
2017-06-30 12:50                     ` Sergey Senozhatsky
2017-06-30 13:16               ` Petr Mladek
2017-06-30 13:38                 ` Sergey Senozhatsky
2017-07-03 11:11                   ` Sergey Senozhatsky [this message]
2017-07-02 20:27                     ` Pavel Machek
2017-07-05 16:36                       ` Sergey Senozhatsky
2017-07-03 19:34                     ` Steven Rostedt
2017-07-04  5:26                       ` Sergey Senozhatsky
2017-07-04  6:53                         ` Sergey Senozhatsky
2017-06-30 14:10                 ` Sergey Senozhatsky
2017-06-30 11:54             ` Petr Mladek
2017-06-30 12:42               ` Sergey Senozhatsky
2017-06-30 13:33                 ` Steven Rostedt
2017-06-30 14:28                   ` Sergey Senozhatsky
2017-06-30 14:45                     ` Steven Rostedt
2017-07-01  1:50                       ` Sergey Senozhatsky
2017-07-04 14:03                 ` Petr Mladek
2017-07-05  5:02                   ` Sergey Senozhatsky
2017-05-09  8:28 ` [RFC][PATCHv3 3/5] printk: add enforce_emergency parameter Sergey Senozhatsky
2017-05-09  8:28 ` [RFC][PATCHv3 4/5] printk: enable printk offloading Sergey Senozhatsky
2017-05-09  8:28 ` [RFC][PATCHv3 5/5] printk: register PM notifier Sergey Senozhatsky
2017-05-30  9:55   ` Petr Mladek
2017-05-31  6:42     ` Sergey Senozhatsky
2017-06-27 14:45       ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170703111130.GA836@jagdpanzerIV.localdomain \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@lisas.de \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.