Messages in this thread |  | | Date | Wed, 18 Aug 2004 14:29:11 -0700 | | From | Elladan <> | | Subject | Re: [patch] voluntary-preempt-2.6.8.1-P3 |
| |
On Wed, Aug 18, 2004 at 03:01:48PM +0200, Florian Schmidt wrote: > On Wed, 18 Aug 2004 14:27:03 +0200 > Ingo Molnar <mingo@elte.hu> wrote: > > > > > Btw: one question: at one point in time the IRQ handlers were in the > > > SCHED_FIFO scheduling class. Why has this changed? > > > > so that they dont starve the audio threads by default - the audio IRQ > > has to get another priority anyway. Maybe we could try a default > > SCHED_FIFO prio lower than the typical rt_priority of jackd - e.g. 30? > > Oh, upon rereading the chrt manpage i found out why i failed to set them > to SCHED_FIFO manually. So it was my error. I thought the > scheduling of the IRQ handlers was not changable at runtime. Thus my > question to make them SCHED_FIFO by default. > > Well, i still think they should be SCHED_FIFO by default, so no user > process that is not itself SCHED_FIFO can starve them [X11 was able to > starve mouse irq's on my system with the defualt IRQ handlers > running SCHED_OTHER FWIW]. To make starving of user-SCHED_FIFO processes > unprobably maybe use a default static prio of 0. > > Afaik jackd uses priorities > 0 for its audio threads when runing > SCHED_FIFO anyways.. > > But since the user will have to tweak his IRQ handlers manually anyways > [set soundcard irq higher prio than the rest, etc..], it doesn't really > make a difference.
This doesn't take into account SCHED_RR processes, which expect to behave just like SCHED_FIFO unless there's another SCHED_RR process of the same priority...
-J - 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/
|  |