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

[Peter Williams <pwil3058@bigpond.net.au>]

Bill Huey (hui) wrote:
> On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
> 
>>Ingo Molnar <mingo@elte.hu> 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. :)

As Ingo said in an earlier a post, with a little ingenuity this problem 
can be solved in user space.  The programs in question can be setuid 
root so that they can set RT scheduling policy BUT have their 
permissions set so that they only executable by owner and group with the 
group set to a group that only contains those users that have permission 
to run this program in RT mode.  If you wish to allow other users to run 
the program but not in RT mode then you would need two copies of the 
program: one set up as above and the other with normal permissions.

It may be necessary for users that are members of this RT group to do a 
newgrp before running this program if it isn't their primary group.  But 
that could be done in a shell wrapper.

If you have the source code for the programs then they could be modified 
to drop the root euid after they've changed policy.  Or even do the 
group membership check inside the program and if the user that launches 
the program is not a member of the group drop root euid immediately on 
start up.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce