|| ||Ingo Molnar <firstname.lastname@example.org>|
|| ||Jack O'Quin <email@example.com>|
|| ||[patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable|
|| ||Mon, 24 Jan 2005 13:58:14 +0100|
|| ||Paul Davis <firstname.lastname@example.org>,
Con Kolivas <email@example.com>,
linux <firstname.lastname@example.org>, email@example.com,
CK Kernel <firstname.lastname@example.org>, utz <email@example.com>,
Andrew Morton <firstname.lastname@example.org>, email@example.com,
Rui Nuno Capela <firstname.lastname@example.org>,
Chris Wright <email@example.com>,
Arjan van de Ven <firstname.lastname@example.org>,
Nick Piggin <email@example.com>|
* Ingo Molnar <firstname.lastname@example.org> wrote:
> [...] "how do we give low latencies to audio applications (and other,
> soft-RT alike applications), while not allowing them to lock up the
ok, here is another approach, against 2.6.10/11-ish kernels:
this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
amount of CPU time all RT tasks combined may use, in percent. Defaults
just apply the patch to 2.6.11-rc2 and you should be able to run e.g.
"jackd -R" as an unprivileged user.
note that this allows the use of SCHED_FIFO/SCHED_RR policies, without
the need to add any new scheduling classes. The RT CPU-limit acts on the
existing RT-scheduling classes, by adding a pretty simple and
straightforward method of tracking their CPU usage, and limiting them if
they exceed the threshold. As long as the treshold is not violated the
scheduling/latency properties of those scheduling classes remains.
It would be very interesting to see how jackd/jack_test performs with
this patch applied, and rt_cpu_limit is set to different percentages,
compared against unpatched SCHED_FIFO performance.
other properties of rt_cpu_limit:
- if there's idle time in the system then RT tasks will be
allowed to use more than the limit. Once SCHED_OTHER tasks
are present again, the limit is enforced.
- if an RT task goes above the limit all the time then there
is no guarantee that exactly the limit will be allowed for
it. (i.e. you should set the limit to somewhat above the real
needs of the RT task in question.)
- zero rt_cpu_limit value means unlimited CPU time to all
- a nonzero rt_cpu_limit value also has the effect of allowing
the use of RT scheduling classes/priorities for nonprivileged
users. I.e. a value of 100% differs from a value of 0 in that 0
doesnt allow RT priorities for ordinary users.
- on SMP the limit is measured and enforced per-CPU.
- runtime overhead is minimal, especially if the limit is set to 0.
- the CPU-use measurement code has a 'memory' of roughly 300 msecs.
I.e. if an RT task runs 100 msecs nonstop then it will increase
its CPU use by about 30%. This should be fast enough for users for
the limit to be human-inperceptible, but slow enough to allow
occasional longer timeslices to RT tasks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/