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

["Jack O'Quin" <joq@io.com>]

Bill Huey (hui) <bhuey@lnxw.com> writes:

> Also, as media apps get more sophisticated they're going to need some
> kind of access to the some traditional softirq facilities, possibily
> migrating it into userspace safely somehow, with how it handles IO
> processing such as iSCSI, FireWire, networking and all peripherals
> that need some kind of prioritized IO handling. It's akin to O_DIRECT,
> where folks need to determine policy over the kernel's own facilities,
> IO queues, but in a more broad way. This is inevitable for these
> category of apps. Scary ? yes I know.

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.  

This is really only useful within the context of a dedicated realtime
system, of course.

Stephane Letz reports a similar feature in Mac OS X.

> Whether this suitable for main stream inclusion is another matter. But
> as a person that wants to write apps of this nature, I came into this
> kernel stuff knowing that there's going to be a conflict between the
> the needs of media apps folks and what the Linux kernel folks will
> tolerate as a community.

That's a price both groups pay for doing realtime within the context
of a general-purpose OS.  But, for many, many applications it's the
best option.

Fortunately, most of what we need also improves the general quality
and responsiveness of the kernel.  The important things like short
lock hold times are really just good concurrent programming practice.

>> The cost/performance characteristics of commodity PC's running Linux
>> are quite compelling for a wide range of practical realtime
>> applications.  But, these are dedicated machines.  The whole system
>> must be carefully tuned.  That is the only method that actually works.
>> The scheduler is at most a peripheral concern; the best it can do is
>> not screw up.
>
> It's very compelling and very deadly to the industry if these things
> become common place in the normal Linux kernel. It would instantly
> make Linux the top platform for anything media related, graphic and
> audio.

Yes, many people want to take advantage of this.
-- 
  joq