LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Max Krasnyanskiy <maxk@qualcomm.com>
Cc: Steven Rostedt <srostedt@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: RT scheduler config, suggestions and questions
Date: Wed, 06 Feb 2008 07:36:55 +0100	[thread overview]
Message-ID: <1202279815.19243.34.camel@lappy> (raw)
In-Reply-To: <47A8F328.5070107@qualcomm.com>


On Tue, 2008-02-05 at 15:37 -0800, Max Krasnyanskiy wrote:
> Folks,
> 
> I just realized that in latest Linus' tree following sysctls are under SCHED_DEBUG:
> 	sched_rt_period
> 	sched_rt_ratio
> 
> I do not believe that is correct. I know that we do not want to expose scheduler knobs
> in general but theses are not the heuristic kind of knobs. There is no way the scheduler 
> can magically figure out what the correct setting should be here.

Yeah, since fixed.

> Also shouldn't those new RT features that recently went be configurable and _disabled_ 
> by default ? For example "RT watchdog" and "RT throttling" actually seem very questionable. 
> SCHED_FIFO is clearly defined as
> "
>   A SCHED_FIFO process runs until either it is blocked by an I/O request, it is preempted 
>   by a higher priority process, or it calls sched_yield(2).
> "

The watchdog is disabled by default, the bandwidth is .95s every 1s,
which is mainly a safe-guard against run-away real-time tasks. As long
as real-time usage stays within those limits nothing happens. If you
don't like it set sched_rt_runtime [*] to -1.

[*] provided in the interface changes posted a few days ago.

> Both the watchdog and the throttling are clearly braking that rule. I think it's good to have 
> those features but not enabled by default and certainly not with sysctls that disable them 
> hidden under debugging.
> How about this:
> - We introduce Kconfig options for them ?

I don't see why this would be needed.

> - Expose all rt sysctls outside of #ifdef DEBUG

Already did this somewhere along the line.

> btw I can see "watchdog" being very useful to catch hard-RT tasks that exceed the deadline.
> But's it gotta be per thread.

It is.

> Single setting per user is not enough. Unless a use has a single RT task.

?


  reply	other threads:[~2008-02-06  6:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05 23:37 Max Krasnyanskiy
2008-02-06  6:36 ` Peter Zijlstra [this message]
2008-02-06 11:29   ` Peter Zijlstra
2008-02-06 18:04     ` Max Krasnyanskiy
2008-02-06 21:50       ` Peter Zijlstra
2008-02-06 17:52   ` Max Krasnyanskiy

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=1202279815.19243.34.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=mingo@elte.hu \
    --cc=srostedt@redhat.com \
    --subject='Re: RT scheduler config, suggestions and questions' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).