[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1202279815.19243.34.camel@lappy>
Date: Wed, 06 Feb 2008 07:36:55 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Max Krasnyanskiy <maxk@...lcomm.com>
Cc: Steven Rostedt <srostedt@...hat.com>, Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: RT scheduler config, suggestions and questions
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.
?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists