Messages in this thread | | | Date | Wed, 5 Jan 2005 12:52:13 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
the RT-LSM thing is a bit dangerous because it doesnt really protect against a runaway, buggy app. So i think the right way to approach this problem is to not apply RT-LSM for the time being, but to provide an 'advanced latency needs' scheduling class that is _still_ safe even if the task is runaway, but behaves with near-RT priorities if the task is 'nice' (i.e. doesnt use up large amount of CPU time.)
incidentally, there is such a scheduling class already: negative nice levels. Please skip any preconceptions you might have about nice levels, nice levels have been improved in 2.6.10, the timeslices are now given out exponentially, giving nice -20 tasks far more weight and priority than they used to have. (They are obviously still preemptable if they keep looping burning CPU - but that we can consider a feature.) (Also, in 2.6 the negative nice levels have a much more agressive interactivity setting, allowing them to preempt everything lower-prio.)
so, could you try vanilla 2.6.10 (without LSM and without jackd running with RT priorities), with jackd set to nice -20? Make sure the jack-client process gets this priority too. Best to achieve this is to renice a shell to -20 and start up everything from there - the nice settings will be inherited. How does such an audio test compare to a test done with jackd running at SCHED_FIFO with RT priority 1?
if this works out well then we could achieve something comparable to RT-LSM, via nice levels alone.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |