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

[Florian Schmidt]

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.

No, i will not put a verbatim copy of this onto the wiki. I will try to
extract the relevant information.

> 
> This text describes the Solaris implementation of interrupt threads
> vs. the traditional method.  It applies very well to Ingo's patch.    

Ok

> These <it>kernel
> threads</it> can be created on the fly and are assigned a higher
> priority than all other types of threads.  

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.

> 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..

> 
> With threaded interrupts, an interrupt arriving from the disk
> controller does not immediately cause the disk irq handler to run,
> interrupting whatever was going on, but marks the disk irq thread as
> ready to run. Since interrupt threads run at the highest priority,
> this will usually cause the disk irq handler to be scheduled and run
> immediately, unless we are executing a *non-threaded* interrupt
> handler.  This is the advantage of the mixed model - where the
> soundcard interrupt handler would previously have been interrupted, in
> this case the disk irq handler will run as soon as the soundcard irq
> handler exits.

Yes, this makes sense.. 

> 
> By default, if all irqs are threaded, all the threads run at the same
> priority.  This means that if we get interrupts from both the
> soundcard and disk while a third handler is running (say the timer).
> both will be queued, and possibly the disk irq thread will get
> scheduled before the soundcard irq thread, leading to xruns.
> 
> I believe you could achieve the same result as setting the soundcard
> irq non-threaded by having all irqs threaded, and setting the priority
> for the soundcard interrupt handler thread higher than the others.  I
> have not tested this.

Me neither, but it makes sense..

-- 
Palimm Palimm!
http://affenbande.org/~tapas/