Messages in this thread | | | Date | Wed, 18 Aug 2004 15:01:48 +0200 | From | Florian Schmidt <> | Subject | Re: [patch] voluntary-preempt-2.6.8.1-P3 |
| |
On Wed, 18 Aug 2004 14:27:03 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > * Florian Schmidt <mista.tapas@gmx.net> wrote: > > > Hi, it applied against 2.6.8.1 with some offsets and some buzz [?]. > > Well anyways it compiled fine and the copy_page_range latency is > > gone.. Now i also see the extracty entropy thing, too.. > > could you try the attached patch that changes SHA_CODE_SIZE to 3 - > does this reduce the latency caused by extract_entropy?
will do..
> > > 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.
Flo
-- Palimm Palimm! http://affenbande.org/~tapas/
- 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/
| |