From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
pmladek@suse.cz, Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 8/8] printk: Add config option for disabling printk offloading
Date: Wed, 26 Mar 2014 17:23:32 +0000 [thread overview]
Message-ID: <20140326172332.5f1e1bfb@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1395770101-24534-9-git-send-email-jack@suse.cz>
On Tue, 25 Mar 2014 18:55:01 +0100
Jan Kara <jack@suse.cz> wrote:
> 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.
If its an option it'll not get used. It ought to be automatic.
I still think the mindset of this patch set is wrong. Only the device
driver really knows what is good or bad. A large x86 connected to a
network fake 16x50 serial port for example typically has a giant FIFO so
'bad' becomes 32K not 1000. A USB serial port already does async queueing
so the value is 0.
It also ignores priority so you might queue and loose an oops as a box
goes down in preference to reporting debugging crap.
All the afflicted consoles are serial, all go via the uart layer as far
as I can see.
The uart layer has a queue mechanism that could be used
Alan
next prev parent reply other threads:[~2014-03-26 17:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 17:54 [PATCH 0/8 v4] printk: Cleanups and softlockup avoidance Jan Kara
2014-03-25 17:54 ` [PATCH 1/8] printk: Remove outdated comment Jan Kara
2014-03-25 17:54 ` [PATCH 2/8] printk: Release lockbuf_lock before calling console_trylock_for_printk() Jan Kara
2014-04-23 20:56 ` Andrew Morton
2014-04-24 10:18 ` Jan Kara
2014-03-25 17:54 ` [PATCH 3/8] printk: Enable interrupts " Jan Kara
2014-03-25 17:54 ` [PATCH 4/8] printk: Remove separate printk_sched buffers and use printk buf instead Jan Kara
2014-05-05 18:37 ` Steven Rostedt
2014-03-25 17:54 ` [PATCH 5/8] printk: Hand over printing to console if printing too long Jan Kara
2014-03-25 17:54 ` [PATCH 6/8] printk: Start printing handover kthreads on demand Jan Kara
2014-03-26 17:16 ` One Thousand Gnomes
2014-03-26 19:06 ` Jan Kara
2014-03-25 17:55 ` [PATCH 7/8] kernel: Avoid softlockups in stop_machine() during heavy printing Jan Kara
2014-03-25 17:55 ` [PATCH 8/8] printk: Add config option for disabling printk offloading Jan Kara
2014-03-26 17:23 ` One Thousand Gnomes [this message]
2014-03-26 19:28 ` Jan Kara
2014-04-18 18:54 ` Andrew Morton
2014-04-22 10:22 ` One Thousand Gnomes
2014-04-23 11:08 ` Jan Kara
2014-04-23 12:35 ` One Thousand Gnomes
2014-04-23 14:29 ` Jan Kara
2014-04-23 18:17 ` Andrew Morton
2014-04-23 21:16 ` One Thousand Gnomes
2014-04-23 21:41 ` Jiri Kosina
2014-04-24 14:00 ` One Thousand Gnomes
2014-05-15 21:28 ` Jan Kara
2014-04-23 9:30 ` Jan Kara
2014-04-08 14:27 ` [PATCH 0/8 v4] printk: Cleanups and softlockup avoidance Jan Kara
2014-04-08 19:02 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2014-03-14 16:21 [PATCH 0/8 v3] " Jan Kara
2014-03-14 16:21 ` [PATCH 8/8] printk: Add config option for disabling printk offloading 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=20140326172332.5f1e1bfb@alan.etchedpixels.co.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--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 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.