Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 2 Feb 2005 22:21:00 +0100 | From | Ingo Molnar <> | Subject | Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature |
| |
* 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 - 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/
| ![\](/images/icornerr.gif) |