* Bill Huey <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
