Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270551AbTGNHFO (ORCPT ); Mon, 14 Jul 2003 03:05:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270554AbTGNHFO (ORCPT ); Mon, 14 Jul 2003 03:05:14 -0400 Received: from x35.xmailserver.org ([208.129.208.51]:10881 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S270551AbTGNHFJ (ORCPT ); Mon, 14 Jul 2003 03:05:09 -0400 X-AuthUser: davidel@xmailserver.org Date: Mon, 14 Jul 2003 00:12:14 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mcafeelabs.com To: Mike Galbraith cc: Linux Kernel Mailing List Subject: Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ... In-Reply-To: <5.2.1.1.2.20030714063443.01bcc5f0@pop.gmx.net> Message-ID: References: <5.2.1.1.2.20030714063443.01bcc5f0@pop.gmx.net> 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: 1720 Lines: 42 On Mon, 14 Jul 2003, Mike Galbraith wrote: > At 02:51 PM 7/13/2003 -0700, Davide Libenzi wrote: > > >This should (hopefully) avoid other tasks starvation exploits : > > > >http://www.xmailserver.org/linux-patches/softrr.html > > Yes, that ~works. I couldn't starve root to death as a SCHED_SOFTRR user, > but the system was very sluggish, with keystrokes taking uncomfortably > long. I also had some sound skips due to inheritance. If I activate > xmms's gl visualization under load, it inherits SCHED_SOFTRR, says "oink" > in a very deep voice, and other xmms threads expire. Maybe tasks shouldn't > inherit SCHED_SOFTRR? You might want to increase the K_something from 4 (25% CPU time) to a lower value. Also, SOFTRR tasks should get a lower timeslice while they're currently getting the RR one. The SOFTRR policy should be used by MM apps in a way that the thread that uses it does the minimum amount of work in there. Like the thing we do with IRQ processing. > While testing, I spotted something pretty strange. It's not specific to > SCHED_SOFTRR, SCHED_RR causes it too. If I fire up xmms's gl visualization > with either policy, X stops getting enough sleep credit to stay at a usable > priority even when cpu usage is low. Fully repeatable weirdness. See > attached top snapshots. RT tasks are pretty powerfull and should not be used to run everything ;) What I was seeking with this patch was 1) deterministic latency 2) stave protection. - Davide - 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/