From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
mhocko@suse.cz, Steven Rostedt <rostedt@goodmis.org>,
Jan Kara <jack@suse.cz>
Subject: [PATCH 0/4 v6] Avoid softlockups in console_unlock()
Date: Thu, 7 Nov 2013 22:48:35 +0100 [thread overview]
Message-ID: <1383860919-1883-1-git-send-email-jack@suse.cz> (raw)
Hello,
This is the next iteration of my printk patchset. Since v5 I've made the
limit for printing configurable via kernel parameter and let it default to 0.
So unless user sets printk.offload_chars on kernel command line, there will
be no difference to current printk behavior.
Summary:
These patches avoid softlockups when a CPU gets caught in console_unlock() for
a long time during heavy printing from other CPU. As is discussed in patch 3/4
it isn't enough to just silence the watchdog because if CPU spends too long in
console_unlock() also RCU will complain, other CPUs can be blocked waiting for
printing CPU to process IPI, and even disk can be offlined because interrupts
would be disabled for too long.
This patch series solves the problem by stopping printing in console_unlock()
after X (tunable) characters and the printing is postponed to irq work. To
avoid hogging a single CPU (irq work gets processed on the same CPU where it
was queued so it doesn't really help to reduce the printing load on that CPU)
we introduce a new type of lazy irq work - IRQ_WORK_UNBOUND - which can be
processed by any CPU.
The patch series has survived my testing without any softlockup reports. I've
tested running sysrq-t (lots of printk output) while inserting modules (to
generate IPIs and also some printk traffic) and also running two delayed works
printing 10 KB of text each. All this was with simulated 9600 baud serial
console.
Honza
next reply other threads:[~2013-11-07 21:48 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 21:48 Jan Kara [this message]
2013-11-07 21:48 ` [PATCH 1/4] printk: Remove separate printk_sched buffers and use printk buf instead Jan Kara
2013-11-07 21:48 ` [PATCH 2/4] irq_work: Provide a irq work that can be processed on any cpu Jan Kara
2013-11-07 22:13 ` Frederic Weisbecker
2013-11-07 22:19 ` Jan Kara
2013-11-07 22:23 ` Frederic Weisbecker
2013-11-07 22:50 ` Jan Kara
2013-11-07 22:54 ` Frederic Weisbecker
2013-11-07 23:01 ` Jan Kara
2013-11-07 23:31 ` Steven Rostedt
2013-11-08 10:18 ` Jan Kara
2013-11-07 22:32 ` Frederic Weisbecker
2013-11-07 21:48 ` [PATCH 3/4] printk: Defer printing to irq work when we printed too much Jan Kara
2013-11-07 22:43 ` Frederic Weisbecker
2013-11-07 22:57 ` Jan Kara
2013-11-07 23:21 ` Frederic Weisbecker
2013-11-07 23:37 ` Steven Rostedt
2013-11-07 23:44 ` Frederic Weisbecker
2013-11-07 23:46 ` Frederic Weisbecker
2013-11-08 10:21 ` Jan Kara
2013-11-22 23:27 ` Andrew Morton
2013-11-25 12:08 ` Jan Kara
2013-11-11 21:54 ` Pavel Machek
2013-11-11 22:17 ` Jan Kara
2013-11-16 11:35 ` Pavel Machek
2013-11-07 22:59 ` Steven Rostedt
2013-11-07 21:48 ` [PATCH 4/4] printk: Use unbound irq work for printing and waking Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2013-08-21 8:08 [PATCH 0/4 v6] Avoid softlockups in console_unlock() Jan Kara
2013-08-21 21:27 ` Andrew Morton
2013-08-21 22:59 ` Jan Kara
2013-08-22 19:49 ` Andrew Morton
2013-08-22 21:57 ` Jan Kara
2013-08-22 22:14 ` Andrew Morton
2013-08-23 19:50 ` Jiri Kosina
2013-08-23 19:48 ` Jiri Kosina
2013-08-23 19:58 ` Andrew Morton
2013-08-26 11:48 ` Jiri Kosina
2013-09-05 15:46 ` Jan Kara
2013-09-19 21:26 ` Andrew Morton
2013-09-20 21:55 ` Jan Kara
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=1383860919-1883-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=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;
as well as URLs for NNTP newsgroup(s).