Subject: Re: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
From: Florian Schmidt (mista.tapas_AT_gmx.net)
Date: Tue Aug 10 2004 - 00:00:08 EEST
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/
This archive was generated by hypermail 2b28 : Mon Aug 09 2004 - 23:52:28 EEST