All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	pmladek@suse.com, rostedt@goodmis.org,
	Gavin Hu <gavin.hu.2010@gmail.com>,
	KY Srinivasan <kys@microsoft.com>, Jan Kara <jack@suse.cz>
Subject: [PATCH 0/4] printk: Softlockup avoidance
Date: Wed, 19 Aug 2015 17:38:27 +0200	[thread overview]
Message-ID: <1439998711-7013-1-git-send-email-jack@suse.com> (raw)

From: Jan Kara <jack@suse.cz>

Hello,

since lately there were several attempts at dealing with softlockups due
to heavy printk traffic [1] [2] and I've been also privately pinged by
couple of people about the state of the patch set, I've decided to respin
the patch set.

To remind the original 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 when printk() gets called under some critical
spinlock or 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.

This series addresses the problem in the following way: If CPU has printed
more that printk_offload (defaults to 1000) characters, it wakes up one
of dedicated printk kthreads (we don't use workqueue because that has
deadlock potential if printk was called from workqueue code). Once we find
out kthread is spinning on a lock, we stop printing, drop console_sem, and
let kthread continue printing. Since there are two printing kthreads, they
will pass printing between them and thus no CPU gets hogged by printing.

Changes since the last posting [3]:
* I have replaced the state machine to pass printing and spinning on
  console_sem with a simple spinlock which makes the code
  somewhat easier to read and verify.
* Some of the patches were merged so I dropped them.

								Honza

[1] https://lkml.org/lkml/2015/7/8/215
[2] http://marc.info/?l=linux-kernel&m=143929238407816&w=2
[3] https://lkml.org/lkml/2014/3/17/68

             reply	other threads:[~2015-08-19 15:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 15:38 Jan Kara [this message]
2015-08-19 15:38 ` [PATCH 1/4] printk: Hand over printing to console if printing too long Jan Kara
2015-09-18 22:14   ` Andrew Morton
2015-09-22 10:27     ` Jan Kara
2015-08-19 15:38 ` [PATCH 2/4] printk: Start printing handover kthreads on demand Jan Kara
2015-08-19 15:38 ` [PATCH 3/4] kernel: Avoid softlockups in stop_machine() during heavy printing Jan Kara
2015-09-18 22:15   ` Andrew Morton
2015-09-22 10:55     ` Jan Kara
2015-09-23  8:37       ` Jan Kara
2015-08-19 15:38 ` [PATCH 4/4] printk: Add config option for disabling printk offloading Jan Kara
2015-09-18 22:15   ` Andrew Morton
2015-09-22 11:51     ` Jan Kara
2015-08-20  2:37 ` [PATCH 0/4] printk: Softlockup avoidance KY Srinivasan
2015-09-18 22:14 ` Andrew Morton
2015-09-22 10:10   ` 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=1439998711-7013-1-git-send-email-jack@suse.com \
    --to=jack@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=gavin.hu.2010@gmail.com \
    --cc=jack@suse.cz \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --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 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.