Re: [PATCH] O13int for interactivity

From: William Lee Irwin III <wli@holomorphy.com>
To: Rob Landley <rob@landley.net>
Cc: Con Kolivas <kernel@kolivas.org>, Andrew Morton <akpm@osdl.org>,
	piggin@cyberone.com.au, linux-kernel@vger.kernel.org,
	mingo@elte.hu, felipe_alfaro@linuxmail.org
Subject: Re: [PATCH] O13int for interactivity
Date: Mon, 11 Aug 2003 08:58:48 -0700	[thread overview]
Message-ID: <20030811155848.GE32488@holomorphy.com> (raw)
In-Reply-To: <200308110257.25601.rob@landley.net>

On Mon, Aug 11, 2003 at 02:57:25AM -0400, Rob Landley wrote:
> It seems that there's a special case, where a task that was blocked on a read 
> (either from a file or from swap) wants to be scheduled immediately, but with 
> a really short timeslice.  I.E. give it the ability to submit another read 
> and block on it immediately, but if a single jiffy goes by and it hasn't done 
> it, it should go away.
> This has nothing to do with the normal priority levels or being considered 
> interactive or not.  As I said, a special case.  IO_UNBLOCKED_FLAG or some 
> such.  Maybe unnecessary...
> (Once again, the percentage of CPU time to devote to a task and the immediacy 
> of scheduling that task are in opposition.  The "priority" abstraction is a 
> bit too simple at times...)

This is bandwidth vs. latency. Priority isn't directly correlated to
either. There are patches floating around for more explicit cpu
bandwidth control (which IMHO would be ideal for the xmms problem).
Differentiated service with respect to latency is a bit of a different
story, and appears to have more complex semantics (!= complex code!)
than bandwidth.

-- wli