wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)

[Lee Revell]

On Mon, 2004-08-09 at 17:00, Florian Schmidt wrote:
> On Mon, 09 Aug 2004 14:05:26 -0400
> Lee Revell <rlrevell at joe-job.com> wrote:
> 
> > Here is an excerpt from "Unix Internals" by Uresh Vahalia that
> > explains the situation much better than I could.  I am not sure what
> > the copyright implications of posting this are, possibly it is short
> > enough to be OK, but I will let you be the judge of whether to post it
> > on the wiki.
> 

OK.  I am going to plug the book however because it's so good:
http://www.amazon.com/exec/obidos/tg/detail/-/0131019082?v=glance.

> This seems to be not true for the threaded IRQ handlers in VP [top
> extract]:
> 
> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 118 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 IRQ 5        
>                                    
> mango:~# chrt -p 118
> pid 118's current scheduling policy: SCHED_OTHER
> pid 118's current scheduling priority: 0
> 
> Or do chrt and top print wrong infos? Or do i just read them wrong? I'm
> especially amazed about the SCHED_OTHER.
> 

You are correct, they run at the same elevated priority as all kernel
threads, not higher.  This would explain why X activity can delay the
interrupt handlers with the default settings - on Debian the X server
runs at nice -10.  I am pretty sure that one patch series (-L or -M) ran
the interrupt threads reniced to -51.

> > Basically, with non-threaded interrupts, anytime an interrupt occurs
> > the interrupt handler runs immediately, blocking additional interrupts
> > from the same device while it is running.  This means than an
> > interrupt handler can interrupt another interrupt handler, say, if we
> > get a disk i/o completion in the middle of snd_pcm_period_elapsed.
> 
> Hmm, isn't it the case that the traditional IRQ handler blocks all
> further IRQ's until it is done? I suppose there was a hierarchy of some
> kind. I read about the ipl in the text you quoted but didn't understand
> it really..
> 

I think Linux does not have ipls as such.  When an interrupt handler is
running it blocks further interrupts from the same source, but without
the voluntary preempt patch, an interrupt from the disk will interrupt
the soundcard interrupt handler.  If you were to extend this scheme to
support more than one priority (as opposed to 'this interrupt source' vs
'other interrupt source'), you would have IPLs.

I think that threading all interrupts and setting relative priorities
would give you IPLs on Linux.  More testing is required.

Lee