lkml.org 
[lkml]   [2004]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
Hi!

> > Well, I do not follow you I guess.
> >
> > With large-enough number of hardirqs you do no progress at all.
> >
> > Even if only "sane" number of irqs, if they all decide to hit within one
> > getpid(), this getpid is going to take quite long....
> > Pavel
>
> Ordinarily, yes. However, if it's a high-priority RT task that does
> the getpid(), whose priority is higher than that of the RT tasks,
> you'll get at most one hardirq stub per active IRQ number; after
> that, the IRQs will be masked until their threads get a chance to be
> scheduled.

But will not even num_IRQs*time_per_stub be so high that any analysis
is impractical?

...

...

Hmm, that high-priority hask only has to eat num_IRQs*time_per_stub
once, so perhaps its okay.
Pavel

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.187 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site