Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262276AbVBBLLy (ORCPT ); Wed, 2 Feb 2005 06:11:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262269AbVBBLLy (ORCPT ); Wed, 2 Feb 2005 06:11:54 -0500 Received: from smtp.Lynuxworks.com ([207.21.185.24]:34828 "EHLO smtp.lynuxworks.com") by vger.kernel.org with ESMTP id S262276AbVBBLLd (ORCPT ); Wed, 2 Feb 2005 06:11:33 -0500 Date: Wed, 2 Feb 2005 03:10:45 -0800 To: "Jack O'Quin" Cc: Ingo Molnar , Nick Piggin , Paul Davis , Con Kolivas , linux , rlrevell@joe-job.com, CK Kernel , utz , Andrew Morton , alexn@dsv.su.se, Rui Nuno Capela , Chris Wright , Arjan van de Ven , "Bill Huey (hui)" Subject: Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature Message-ID: <20050202111045.GA12155@nietzsche.lynx.com> References: <20050125135613.GA18650@elte.hu> <87sm4opxto.fsf@sulphur.joq.us> <20050126070404.GA27280@elte.hu> <87fz0neshg.fsf@sulphur.joq.us> <1106782165.5158.15.camel@npiggin-nld.site> <874qh3bo1u.fsf@sulphur.joq.us> <1106796360.5158.39.camel@npiggin-nld.site> <87pszr1mi1.fsf@sulphur.joq.us> <20050127113530.GA30422@elte.hu> <873bwfo8br.fsf@sulphur.joq.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873bwfo8br.fsf@sulphur.joq.us> User-Agent: Mutt/1.5.6+20040907i From: Bill Huey (hui) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4008 Lines: 76 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. :) bill - 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/