All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Jan Kara <jack@suse.cz>,
	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 6/8] printk: Start printing handover kthreads on demand
Date: Wed, 26 Mar 2014 20:06:15 +0100	[thread overview]
Message-ID: <20140326190615.GB18118@quack.suse.cz> (raw)
In-Reply-To: <20140326171641.0e117018@alan.etchedpixels.co.uk>

On Wed 26-03-14 17:16:41, One Thousand Gnomes wrote:
> On Tue, 25 Mar 2014 18:54:59 +0100
> Jan Kara <jack@suse.cz> wrote:
> 
> > Start kthreads for handing over printing only when printk.offload_chars
> > is set to value > 0 (i.e., when print offloading gets enabled).
> 
> The original set it was suggested that having all these threads around
> that 99.99999% of users don't need was a waste and why not start them
> when needed. Also I asked why you couldn't just schedule_work the jobs
> onto CPUs instead.
> 
> I don't recall seeing a reply to that - and it doesn't appear fixed here ?
  I replied to you (https://lkml.org/lkml/2014/3/14/176) regarding why
people refused schedule_work() to be used.

  Regarding starting threads only when needed: Starting threads from
console_unlock() is IHMO a no-go because that can happen in a context in
which we cannot just call create_kthread(). So the solution I proposed -
and noone really objected - was what this patch does. Also note that we
agreed with Andrew that after this feature gets some testing, we will
change the default to disabled so that most people don't pay the
unnecessary overhead.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2014-03-26 19:06 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 [this message]
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
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 6/8] printk: Start printing handover kthreads on demand 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=20140326190615.GB18118@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --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.