Subject: interactive task starvation
From: Mike Galbraith <efault@gmx.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: lkml <linux-kernel@vger.kernel.org>
In-Reply-To: <20060317090653.GC13387@elte.hu>
References: <200603081013.44678.kernel@kolivas.org>
	 <20060307152636.1324a5b5.akpm@osdl.org>
	 <cone.1141774323.5234.18683.501@kolivas.org>
	 <200603090036.49915.kernel@kolivas.org>  <20060317090653.GC13387@elte.hu>
Content-Type: text/plain
Date: Fri, 17 Mar 2006 11:46:15 +0100
Message-Id: <1142592375.7895.43.camel@homer>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1307
Lines: 32

On Fri, 2006-03-17 at 10:06 +0100, Ingo Molnar wrote:

> yep, i think that's a good idea. In the worst case the starvation 
> timeout should kick in.

(I didn't want to hijack that thread ergo name change)

Speaking of the starvation timeout...

I'm beginning to wonder if it might not be a good idea to always have an
expired_timestamp to ensure that there is a limit to how long
interactive tasks can starve _each other_.  Yesterday, I ran some tests
with apache, and ended up waiting for over 3 minutes for a netstat|
grep :81|wc -l to finish when competing with 10 copies of httpd.  The
problem with the expired_timestamp is that if there is nobody already
expired, and if no non-interactive task exists, there's certainly no
expired_timestamp, there's no starvation limit. 

There are other ways to cure 'interactive starvation', but forcing an
array switch if a non-interactive task hasn't run for pick-a-number time
is the easiest.

	-Mike

(yup, folks would certainly feel it, and would _very_ likely gripe, so
it would probably have to be configurable)

-
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/