From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 6 Mar 2003 12:06:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 6 Mar 2003 12:06:56 -0500 Received: from mx2.elte.hu ([157.181.151.9]:31151 "HELO mx2.elte.hu") by vger.kernel.org with SMTP id ; Thu, 6 Mar 2003 12:06:55 -0500 Date: Thu, 6 Mar 2003 18:17:11 +0100 (CET) From: Ingo Molnar Reply-To: Ingo Molnar To: Jeff Garzik Cc: Linus Torvalds , Andrew Morton , Robert Love , Subject: Re: [patch] "HT scheduler", sched-2.5.63-B3 In-Reply-To: <3E6770F3.8030207@pobox.com> Message-ID: 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 On Thu, 6 Mar 2003, Jeff Garzik wrote: > Pardon the suggestion of a dumb hueristic, feel free to ignore me: > would it work to run-first processes that have modified their iopl() > level? i.e. "if you access hardware directly, we'll treat you specially > in the scheduler"? we did this in the Red Hat kernel, just as a quick hack to boost X without having to modify X (bleh). While it worked very well in practice, it's a really bad idea from an interface design POV, because it singles out X mostly based on a random characteristics of X, but leaves out some other tasks that are 'suffering' from not being recognized as interactive, but still having a user watching them (and expecting keypresses to react fast): games, xine, XMMS, etc. > An alternative is to encourage distros to set some sort of flag for > processes like the X server, when it is run. This sounds suspiciously > like the existing "renice X server" hack, but it could be something like > changing the X server from SCHED_OTHER to SCHED_HW_ACCESS instead. yes, an ELF flag might work, or my suggestion to allow applications to increase their priority (up until a certain degree). Ingo