Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261489AbVAGQUb (ORCPT ); Fri, 7 Jan 2005 11:20:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261491AbVAGQUb (ORCPT ); Fri, 7 Jan 2005 11:20:31 -0500 Received: from news.suse.de ([195.135.220.2]:29145 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S261489AbVAGQUV (ORCPT ); Fri, 7 Jan 2005 11:20:21 -0500 Date: Fri, 07 Jan 2005 17:20:09 +0100 Message-ID: From: Takashi Iwai To: Arjan van de Ven Cc: Paul Davis , Christoph Hellwig , Lee Revell , Ingo Molnar , Chris Wright , Alan Cox , "Jack O'Quin" , Linux Kernel Mailing List , Andrew Morton Subject: Re: [PATCH] [request for inclusion] Realtime LSM In-Reply-To: <20050107160350.GB29327@devserv.devel.redhat.com> References: <20050107153328.GD28466@devserv.devel.redhat.com> <200501071541.j07FfeQC018553@localhost.localdomain> <20050107160350.GB29327@devserv.devel.redhat.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1550 Lines: 33 At Fri, 7 Jan 2005 17:03:51 +0100, Arjan van de Ven wrote: > > On Fri, Jan 07, 2005 at 10:41:40AM -0500, Paul Davis wrote: > > > > fine, so the mlock situation may have improved enough post-2.6.9 that > > it can be considered fixed. that leaves the scheduler issue. but > > apparently, a uid/gid solution is OK for mlock, and not for the > > scheduler. am i missing something? > > I think you skipped a step. You don't have a scheduler requirement, you have > a latency requirement. You currently *solve* that latency requirement via a > scheduler "hack", yet is quite clear that the "hard" realtime solution is > most likely not the right approach. Note that I'm not saying that you > shouldn't get the latency that that currently provides, but the downsides > (can hang the machine) are bad; a solution that solves that would be far > preferable > something like a soft realtime flag that acts as if it's the hard realtime > one unless the app shows "misbehavior" (eg eats its timeslice for X times in > a row) might for example be such a solution. And with the anti abuse > protection it can run with far lighter privilegs. This reminds me about the soft-RT patch posted quite sometime ago. I feel such a handy psuedo-RT scheduler class would be useful for other systems than JACK, too... Takashi - 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/