Subject: [with RFC] Developers - Priorities... Was: Re: [linux-audio-dev] user lowlatency kernel experience
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Wed Jun 13 2001 - 19:28:56 EEST
Do both csound and timidity run with MAX SCHED_FIFO prio?
Then this will be a big problem...
I guess most people has followed Bennos example code to the
exact word - including running max prio.
* Developers - you should not do this...
(It is fine when testing for the absolute best possible latencies...)
Most systems do not have any processes running SCHED_FIFO
so using the minimum SCHED_FIFO priority should be enough.
Let the highest priorities be free for stuff were it really matters -
like a process for monitoring audio processes and killing hung ones...
(if the hung one has max prio no monitor can get a time slice to be
able to determine that it is hung...)
General rule:
shorter bursts gives you the right to use higher prios
long calculation burst requires low prios - can still be SCHED_FIFO.
but, more important stuff get the right to use higher prios...
- seriously, audio stuff are not that important...
Here comes the RFCs part:
I have been playing with the thought of implementing a "virtual" SCHED class
SCHED_MM were the priority requested really has to be backed up by
how the processor is used
- a priority matches a max burst "time" and a min sleep.
If you try to use the processor for longer or more often that that your
process will be killed! (some sort of burst CPU quota)
Since it will have those strict rules it should be possible to use from a
program without root privileges... (requests can be rejected if the total
requested CPU usage is over some configurable limit)
BUT - how to configure the "time" in such a way that a process can request
a priority and know what it will get, note that processors might change their
frequency nowadays...
/RogerL
On Wednesday 13 June 2001 15:30, you wrote:
> hello,
>
> would just like to tell you of my experience with a low-latency kernel.
>
> i tried kernel 245 with the low-latency patch. to test the system i
> tried using timidity and csound at the same time, driven by jazz.
>
>
> both csound and timidity run as root with the high priority scheduling
> activated.
>
> my experience was that it became very easy to hang the system.if csound
> got to many notes, it would render forever end never return, thus
> effectively hanging my machine.
>
> since the increase in performance wasnt really all that great in my
> case, i have now disabled the low-latency flag, fortunately this can be
> done without recompiling the kernel.
>
> so, since people here seem to think that the low-latency kernel is
> really great, i suspect i have missed something. is there a way to get
> processes to get sceduled promptly, but at the same time not hog the cpu
> if they try?
This archive was generated by hypermail 2b28 : Wed Jun 13 2001 - 21:03:13 EEST