From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
mhocko@suse.cz, pmladek@suse.cz,
Steven Rostedt <rostedt@goodmis.org>, Jan Kara <jack@suse.cz>
Subject: printk: Cleanup and softlockup avoidance
Date: Tue, 17 Dec 2013 15:48:07 +0100 [thread overview]
Message-ID: <1387291691-2224-1-git-send-email-jack@suse.cz> (raw)
Hello,
this is another piece of the printk softlockup saga series. Let me first
remind the problem:
Currently, console_unlock() prints messages from kernel printk buffer to
console while the buffer is non-empty. When serial console is attached,
printing is slow and thus other CPUs in the system have plenty of time
to append new messages to the buffer while one CPU is printing. Thus the
CPU can spend unbounded amount of time doing printing in console_unlock().
This is especially serious since vprintk_emit() calls console_unlock()
with interrupts disabled.
In practice users have observed a CPU can spend tens of seconds printing
in console_unlock() (usually during boot when hundreds of SCSI devices
are discovered) resulting in RCU stalls (CPU doing printing doesn't
reach quiescent state for a long time), softlockup reports (IPIs for the
printing CPU don't get served and thus other CPUs are spinning waiting
for the printing CPU to process IPIs), and eventually a machine death
(as messages from stalls and lockups append to printk buffer faster than
we are able to print). So these machines are unable to boot with serial
console attached. Also during artificial stress testing SATA disk
disappears from the system because its interrupts aren't served for too
long.
---
Since my previous attempts to fix softlockups in printk under heavy load met
some resistance, I've decided to try a different approach - do not let
CPU out of the console_unlock() loop until there's someone else to take over
the printing. However that approach will need some changes in how
smp_call_function_any() works (as I need to make sure someone will come
sooner rather than later to rescue the printing CPU) and I don't want to
make already contentious series even worse. So to move at least by a bit,
let me post the following three patches that improve the situation by not
calling console_unlock() with interrupts disabled. I think they make sense
on their own (the third patch is actually an independent cleanup).
What do you guys think?
Honza
next reply other threads:[~2013-12-17 14:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 14:48 Jan Kara [this message]
2013-12-17 14:48 ` [PATCH 1/3] printk: Release lockbuf_lock before calling console_trylock_for_printk() Jan Kara
2013-12-17 14:48 ` [PATCH 2/3] printk: Enable interrupts " Jan Kara
2013-12-17 14:48 ` [PATCH 3/3] printk: Remove separate printk_sched buffers and use printk buf instead Jan Kara
2013-12-17 17:19 ` Joe Perches
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=1387291691-2224-1-git-send-email-jack@suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
/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®