Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Ingo Molnar <mingo@elte.hu>]

* Bill Huey <bhuey@lnxw.com> wrote:

> On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:

> > I believe Ingo's RT patches already support this on a per-IRQ basis.
> > Each IRQ handler can run in a realtime thread with priority assigned
> > by the sysadmin.  Balancing the interrupt handler priorities with
> > those of other realtime activities allows excellent control.  
> 
> No they don't. That's a physical mapping of these kernel entities, not a
> logic organization that projects upward to things like individual sockets
> or file streams. [...]

yes and no. You are right in that the individual workloads (e.g.
softirqs) are not separated and identified/credited to the thread that
requested them. (in part due to the fact that you cannot e.g. credit a
thread for e.g. unrequested workloads like incoming sockets, or for
'merged' workloads like writeout of a commonly accessed file.)

but Jack is right in practical terms: the audio folks achieved pretty
good results with the current IRQ threading mechanism, partly due to the
fact that the audio stack doesnt use softirqs, so all the
latency-critical activities are in the audio IRQ thread and the
application itself.

	Ingo