Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262084AbVAOBRO (ORCPT ); Fri, 14 Jan 2005 20:17:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262114AbVAOBRL (ORCPT ); Fri, 14 Jan 2005 20:17:11 -0500 Received: from mail.joq.us ([67.65.12.105]:37568 "EHLO sulphur.joq.us") by vger.kernel.org with ESMTP id S262084AbVAOBNm (ORCPT ); Fri, 14 Jan 2005 20:13:42 -0500 To: Mike Galbraith Cc: Arjan van de Ven , Lee Revell , Chris Wright , Paul Davis , Matt Mackall , Christoph Hellwig , Andrew Morton , mingo@elte.hu, alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org, Con Kolivas Subject: Re: [PATCH] [request for inclusion] Realtime LSM References: <20050113214320.GB22208@devserv.devel.redhat.com> <20050111214152.GA17943@devserv.devel.redhat.com> <200501112251.j0BMp9iZ006964@localhost.localdomain> <20050111150556.S10567@build.pdx.osdl.net> <87y8ezzake.fsf@sulphur.joq.us> <20050112074906.GB5735@devserv.devel.redhat.com> <87oefuma3c.fsf@sulphur.joq.us> <20050113072802.GB13195@devserv.devel.redhat.com> <878y6x9h2d.fsf@sulphur.joq.us> <20050113210750.GA22208@devserv.devel.redhat.com> <1105651508.3457.31.camel@krustophenia.net> <20050113214320.GB22208@devserv.devel.redhat.com> <5.2.1.1.2.20050114171907.00c05e38@pop.gmx.net> From: "Jack O'Quin" Date: Fri, 14 Jan 2005 19:14:16 -0600 In-Reply-To: <5.2.1.1.2.20050114171907.00c05e38@pop.gmx.net> (Mike Galbraith's message of "Fri, 14 Jan 2005 18:20:35 +0100") Message-ID: <87llav7atz.fsf@sulphur.joq.us> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1025 Lines: 28 Mike Galbraith writes: > At 05:31 PM 1/13/2005 -0600, Jack O'Quin wrote: >>Yes. However, my tests have so far shown a need for "actual FIFO as >>long as the task behaves itself." > > I for one wonder why that appears to be so. What happens if you use > SCHED_RR instead of SCHED_FIFO? > > (ie is the problem just one of running out of slice at a bad time, or > is it the dynamic priority adjustment) I have no quick and easy test for that. If it's important, I can modify a version of JACK to use SCHED_RR, instead. I very much doubt it would make any difference, since we normally only run one realtime thread at a time. Each client taps the next on the shoulder when it is time for it to run, so there is essentially no concurrency among them. -- joq - 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/