On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote: > Ingo Molnar <[EMAIL PROTECTED]> 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. :) bill - 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/
