mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>
Cc: 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,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads
Date: Fri,  2 Jun 2017 18:03:38 +0900	[thread overview]
Message-ID: <20170602090345.624-1-sergey.senozhatsky@gmail.com> (raw)

Hello,

	RFC

	This patch set adds a printk() SMP kernel threads which let us
to print kernel messages to the console from a non-atomic/schedule-able
context, avoiding different sort of lockups, stalls, etc.

	A completely reworked version, for more details please
see 0003 commit message and code comments/documentation.

	I've managed to reproduce some of the issues with a single printk
kthread solution that Jan Kara talked about. Sometimes scheduler decides
sometimes scheduler decides that printk kthread should run on the same CPU
as the process that is doing printing, so printk kthread never takes over
and systems eventually lockups. With SMP threads we can wake up printk
kthread on a remote CPU (and we know that it will be woken up on a remote
CPU), so per my tests SMP thread-ed version of printing offloading works
much better. But more tests are needed.

	The patch set is in RFC stage. I think I'll move the whole
offloading thing under CONFIG_PRINTK_OFFLOAD (e.g.) at some point.

	As a side note, seems that with the SMP threaded implementation
we can do (there are some constraints (!!), of course) some sort of less
deadlock prone printk. Instead of calling into the scheduler, console_sem,
console_unlock(), we can wake_up printk_kthread on a foreign CPU. So we will
not take scheduler locks or console locks from this CPU. (very-very
schematically):

int vprintk_emit(....)
{
	logbuf_lock_irqsave(flags);

	[..]
	printed_len += log_output(facility, level, lflags, dict, dictlen, text, text_len);

	set_bit(PRINTK_PENDING_OUTPUT, &printk_pending);

	for_each_cpu_and(cpu, cpu_online_mask, &printk_cpumask) {
		if (cpu != smp_processor_id())
			wake_up_process(per_cpu(printk_kthread, cpu));
	}

	logbuf_unlock_irqrestore(flags);
	return printed_len;
}

but, well, there are constraints and limitations.



v3->v4 (Petr, Jan)
-- use SMP kthreads. so every CPU has printk kthread now
-- add syscore notifiers
-- fix 0001 compilation warnings
-- use proper CPU notifiers return values

v2->v3 (Petr, Pavel, Andreas):
-- rework offloading
-- use PM notifiers
-- dropped some patches, etc. etc.

v1->v2:
-- introduce printk_emergency mode and API to switch it on/off
-- move printk_pending out of per-CPU memory
-- add printk emergency_mode sysfs node
-- switch sysrq handlers (some of them) to printk_emergency
-- cleanus/etc.


Sergey Senozhatsky (7):
  printk: move printk_pending out of per-cpu
  printk: introduce printing kernel SMP threads
  printk: add enforce_emergency parameter
  printk: enable printk offloading
  printk: register PM notifier
  printk: register syscore notifier
  printk: add printk cpumask sysctl

 include/linux/console.h |   3 +
 include/linux/printk.h  |   4 +
 kernel/printk/printk.c  | 385 +++++++++++++++++++++++++++++++++++++++++++++---
 kernel/sysctl.c         |   7 +
 4 files changed, 379 insertions(+), 20 deletions(-)

-- 
2.13.0

             reply	other threads:[~2017-06-02  9:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02  9:03 Sergey Senozhatsky [this message]
2017-06-02  9:03 ` [RFC][PATCHv4 1/7] printk: move printk_pending out of per-cpu Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 2/7] printk: introduce printing kernel SMP threads Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 3/7] printk: add enforce_emergency parameter Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 4/7] printk: enable printk offloading Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 5/7] printk: register PM notifier Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 6/7] printk: register syscore notifier Sergey Senozhatsky
2017-06-02  9:03 ` [RFC][PATCHv4 7/7] printk: add printk cpumask sysctl Sergey Senozhatsky
2017-06-08  8:18 ` [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Sergey Senozhatsky
2017-06-28 13:42   ` Petr Mladek
2017-06-29  7:56     ` Sergey Senozhatsky
2017-06-30 12:11       ` Petr Mladek
2017-06-30 12:45         ` Sergey Senozhatsky

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=20170602090345.624-1-sergey.senozhatsky@gmail.com \
    --to=sergey.senozhatsky@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.work@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®