All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Clark Williams <williams@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	linux-rt-users@vger.kernel.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions
Date: Mon, 20 Apr 2015 10:09:03 -0700	[thread overview]
Message-ID: <20150420170902.GU5561@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150420113554.598e503f@sluggy>

On Mon, Apr 20, 2015 at 11:35:54AM -0500, Clark Williams wrote:
> On Sat, 18 Apr 2015 19:05:42 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > > > 	Real-time priority to use for RCU worker threads (RCU_KTHREAD_PRIO) [0] (NEW) 
> > > > 
> > > > Indeed, Linus complained about this one.  ;-)
> > > 
> > > :-) Yes, it's an essentially unanswerable question.
> > > 
> > > > This Kconfig parameter is a stopgap, and needs a real solution.  
> > > > People with crazy-heavy workloads involving realtime cannot live 
> > > > without it, but that means that most people don't have to care.  I 
> > > > have had solving this on my list, and this clearly increases its 
> > > > priority.
> > > 
> > > So what value do they use, prio 99? 98? It might be better to offer 
> > > this option as a binary choice, and set a given priority. If -rt 
> > > people complain then they might help us in solving it properly.
> > 
> > I honestly do not remember what priority they were using, it is
> > not in email, and I don't keep IRC logs that far back.  Adding
> > linux-rt-users@vger.kernel.org on CC.
> 
> As I recall, we started out using fifo:1, but when you get heavy
> workloads running at higher fifo priorities, we wanted to boost the rcu
> worker threads over those workloads. 
> 
> Currently the irq threads default to fifo:50, so maybe a good
> default choice for the rcu threads on RT is fifo:49. That of course
> presumes rational behavior on the part of application developers. 
> 
> I seem to recall that you and I had a discussion about making this
> value a runtime knob in /sys but that didn't go anywhere. Do we need to
> crank that up again and just use the config as a default/starting
> value? If so then we could just default to fifo:1 and let sysadmins
> tweak the value to match up with the workload. 

The sysfs knob might be nice, but as far as I know nobody has been
complaining about it.

Besides, we already have the rcutree.kthread_prio= kernel-boot parameter.
So how about if the Kconfig parameter selects either SCHED_OTHER
(the default) or SCHED_FIFO:1, and then the boot parameter can be used
to select other values.

That said, if the lack of a sysfs knob has been causing real problems,
let's make that happen.

							Thanx, Paul


  reply	other threads:[~2015-04-20 17:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 18:38 [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions Paul E. McKenney
2015-04-18 13:03 ` Ingo Molnar
2015-04-18 13:34   ` Paul E. McKenney
2015-04-18 14:32     ` Ingo Molnar
2015-04-19  2:05       ` Paul E. McKenney
2015-04-20 16:35         ` Clark Williams
2015-04-20 17:09           ` Paul E. McKenney [this message]
2015-04-20 17:59             ` Clark Williams
2015-04-20 18:20               ` Daniel Bristot de Oliveira
2015-04-20 18:01             ` Steven Rostedt
2015-04-20 18:09               ` Ingo Molnar
2015-04-20 18:21                 ` Steven Rostedt
2015-04-20 18:28                   ` Ingo Molnar
2015-04-20 18:34                     ` Steven Rostedt
2015-04-21  6:42                       ` Ingo Molnar
2015-04-21 13:18                         ` Steven Rostedt
2015-04-21  3:37                   ` Mike Galbraith
2015-04-20 20:40             ` Steven Rostedt
2015-04-20 21:15               ` Paul E. McKenney
2015-04-20 21:50                 ` Clark Williams
2015-04-21  1:22                   ` Paul E. McKenney
2015-04-21 13:12                     ` Steven Rostedt
2015-04-21 15:01                       ` Paul E. McKenney
2015-04-21 15:50                         ` Steven Rostedt
2015-04-21 15:54                           ` Paul E. McKenney

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=20150420170902.GU5561@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=williams@redhat.com \
    /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.