[linux-audio-user] IRQ conflicts, acpi, and linux audio

Florian Schmidt mista.tapas at gmx.net
Sun Nov 27 16:33:26 EST 2005

On Sun, 27 Nov 2005 13:12:46 -0800
Mark Knecht <markknecht at gmail.com> wrote:

> > The ability to prioritize interrupts with the -rt kernel is useful
> > because interrupts can be prevented from interrupting USERSPACE code.
> Cool!

Actually sttictly speaking this isn't true. Any code will be preempted
by an IRQ unless it is running with IRQ's off. The cool thing about -rt
is now that every interrupt handler is split into top half and bottom
half (if it before already was split like this, it is now split in 3
pieces). The top half basically just clears the IRQ line and sets up
some stuff, so the kernel thread _bottom half_ irq handler is notified,
there's something to do.

The top half is extremely fast, so the time which might ever be spent in
IRQ off situation is very short. So any IRQ interrupts user space for
only a very very very short time. And everything else (working on the
interrupt requests, etc) is now subject to scheduler decisions.

The kernel threads which are the IRQ bottom half handlers can be
prioritized with -rt. This gives the user the control to i.e. make the
soundcard bottom half irq handler always have priority over the hd
bottom half irq handler. And even jackd can have higher prio than the hd
bottom half irq handler.

To get this control (to prioritize one over the other) they each have to
have their own kernel thread bottom half irq handler which doesn't work
when they share an irq (though this might evenbe possible).

Anyways, the XT-PIC/APIC priorities only count very little on a -rt
system as the possible time windows in which each top half irq handler
runs is very small, so collisions are unlikely.. It is important though
to have individual irq's to be able to priritize on the level where it

Florian Schmidt

Palimm Palimm!

More information about the Linux-audio-user mailing list