[lkml]   [2005]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
> Ingo Molnar <> writes:
> > (also, believe me, this is not arrogance or some kind of game on our
> > part. If there was a nice clean solution that solved your and others'
> > problems equally well then it would already be in Linus' tree. But there
> > is no such solution yet, at the moment. Moreover, the pure fact that so
> > many patch proposals exist and none looks dominantly convincing shows
> > that this is a problem area for which there are no easy solutions. We
> > hate such moments just as much as you do, but they do happen.)
> The actual requirement is nowhere near as difficult as you imagine.
> You and several others continue to view realtime in a multi-user
> context. That doesn't work. No wonder you have no good solution.

A notion of process/thread scoping is needed from my point of view. How
to implement that is another matter and there are no clear solutions
that don't involve major changes in some way to fundamental syscalls
like fork/clone() and underlying kernel structures from what I see.
The very notion of Unix fork semantics isn't sufficient enough to
"contain" these semantics. It's more about controlling things with
known quantities over time, not about process creation relationships,
and therein lies the mismatch.

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.

Think XFS streaming with guaranteed rate IO, then generalize this for
all things that can be streamed in the kernel. A side note, they'll
also be pegging CPU usage and attempting to draw to the screen at the
same time. It would be nice to have slack from scheduler frames be use
for less critical things such as drawing to the screen.

The policy for scheduling these IO requests maybe divorced from the
actual priority of the thread requesting it which present some problems
with the current Linux code as I understand it.

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.

> The humble RT-LSM was actually optimal for the multi-user scenario:
> don't load it. Then it adds no security issues, complexity or
> scheduler pathlength. As an added benefit, the sysadmin can easily
> verify that it's not there.
> 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. (Hopefully, I can get back to kernel coding RT stuff after this
current distraction that has me reassigned onto an emergency project)

I hope I clarified some of this communication and not completely scare
Ingo and others too much. Just a little bit is ok. :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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