[PATCH 4/4] printk: Add config option for disabling printk offloading
From: Jan Kara
Date: Wed Aug 19 2015 - 11:40:07 EST
From: Jan Kara <jack@xxxxxxx>
Necessity for offloading of printing was observed only for large
systems. So add a config option (disabled by default) which removes most
of the overhead added by this functionality.
Signed-off-by: Jan Kara <jack@xxxxxxx>
---
Documentation/kernel-parameters.txt | 13 +++++++------
init/Kconfig | 14 ++++++++++++++
kernel/printk/printk.c | 21 +++++++++++++++++++++
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4e0d2d8c0f97..0ed7f0f1d87a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2943,18 +2943,19 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
default: disabled
- printk.offload_chars=
+ printk.offload_chars= [KNL]
Printing to console can be relatively slow especially
in case of serial console. When there is intensive
printing happening from several cpus (as is the case
during boot), a cpu can be spending significant time
(seconds or more) doing printing. To avoid softlockups,
lost interrupts, and similar problems other cpus
- will take over printing after the currently printing
- cpu has printed 'printk.offload_chars' characters.
- Higher value means possibly longer interrupt and other
- latencies but lower overhead of printing due to handing
- over of printing.
+ will take over printing (if CONFIG_PRINTK_OFFLOAD=y)
+ after the currently printing cpu has printed
+ 'printk.offload_chars' characters. Higher value means
+ possibly longer interrupt and other latencies but
+ lower overhead of printing due to handing over of
+ printing.
Format: <number> (0 = disabled)
default: 1000
diff --git a/init/Kconfig b/init/Kconfig
index af09b4fb43d2..71b296483d0d 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1439,6 +1439,20 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_OFFLOAD
+ default y
+ bool "Enable support for offloading printing to different CPU"
+ depends on PRINTK
+ help
+ Printing to console can be relatively slow especially in case of
+ serial console. On large machines when there is intensive printing
+ happening from several cpus (as is the case during boot), a cpu can
+ be spending significant time (seconds or more) doing printing. To
+ avoid softlockups, lost interrupts, and similar problems other cpus
+ will take over printing after the currently printing cpu has printed
+ certain number of characters (tunable via 'printk.offload_chars'
+ kernel parameter).
+
config BUG
bool "BUG() support" if EXPERT
default y
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c443f1aa7e84..63d78ab19278 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -79,6 +79,7 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_PRINTK_OFFLOAD
/*
* This spinlock is taken when printing to console. It is used only so that
* we can spin on it when some other thread wants to take over printing to
@@ -105,6 +106,7 @@ static DEFINE_MUTEX(printk_kthread_mutex);
/* Wait queue printing kthreads sleep on when idle */
static DECLARE_WAIT_QUEUE_HEAD(print_queue);
+#endif /* CONFIG_PRINTK_OFFLOAD */
#ifdef CONFIG_LOCKDEP
static struct lockdep_map console_lock_dep_map = {
@@ -308,6 +310,7 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
static char *log_buf = __log_buf;
static u32 log_buf_len = __LOG_BUF_LEN;
+#ifdef CONFIG_PRINTK_OFFLOAD
static int offload_chars_set(const char *val, const struct kernel_param *kp);
static struct kernel_param_ops offload_chars_ops = {
.set = offload_chars_set,
@@ -326,6 +329,7 @@ module_param_cb(offload_chars, &offload_chars_ops, &printk_offload_chars,
S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(offload_chars, "offload printing to console to a different"
" cpu after this number of characters");
+#endif
/* Return log buffer address */
char *log_buf_addr_get(void)
@@ -2255,6 +2259,7 @@ out:
raw_spin_unlock_irqrestore(&logbuf_lock, flags);
}
+#ifdef CONFIG_PRINTK_OFFLOAD
/*
* Returns true iff there is other cpu waiting to take over printing. This
* function also takes are of setting PRINTK_HANDOVER_B if we want to hand over
@@ -2278,6 +2283,14 @@ static bool cpu_stop_printing(int printed_chars)
return false;
}
+#else
+
+static bool cpu_stop_printing(int printed_chars, bool *woken)
+{
+ return false;
+}
+
+#endif
/**
* console_unlock - unlock the console system
@@ -2316,7 +2329,9 @@ void console_unlock(void)
/* flush buffered message fragment immediately to console */
console_cont_flush(text, sizeof(text));
again:
+#ifdef CONFIG_PRINTK_OFFLOAD
spin_lock(&print_lock);
+#endif
for (;;) {
struct printk_log *msg;
size_t ext_len = 0;
@@ -2399,12 +2414,14 @@ skip:
console_locked = 0;
up_console_sem();
+#ifdef CONFIG_PRINTK_OFFLOAD
/*
* Release print_lock after console_sem so that printing_task()
* succeeds in getting console_sem (unless someone else takes it and
* then he'll be responsible for printing).
*/
spin_unlock(&print_lock);
+#endif
/*
* Subtlety: We have interrupts disabled iff hand_over == false (to
@@ -2770,6 +2787,7 @@ int unregister_console(struct console *console)
}
EXPORT_SYMBOL(unregister_console);
+#ifdef CONFIG_PRINTK_OFFLOAD
/* Kthread which takes over printing from a CPU which asks for help */
static int printing_task(void *arg)
{
@@ -2838,6 +2856,7 @@ static int offload_chars_set(const char *val, const struct kernel_param *kp)
mutex_unlock(&printk_kthread_mutex);
return 0;
}
+#endif /* CONFIG_PRINTK_OFFLOAD */
static int __init printk_late_init(void)
{
@@ -2850,9 +2869,11 @@ static int __init printk_late_init(void)
}
hotcpu_notifier(console_cpu_notify, 0);
+#ifdef CONFIG_PRINTK_OFFLOAD
mutex_lock(&printk_kthread_mutex);
printk_start_offload_kthreads();
mutex_unlock(&printk_kthread_mutex);
+#endif
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/