Message-ID: <1059382204.3f24e3bc32d56@kolivas.org>
Date: Mon, 28 Jul 2003 18:50:04 +1000
From: Con Kolivas <kernel@kolivas.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] sched-2.6.0-test1-G6, interactivity changes
References: <Pine.LNX.4.44.0307280921360.3537-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.44.0307280921360.3537-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
User-Agent: Internet Messaging Program (IMP) 3.2.1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1304
Lines: 31

Quoting Ingo Molnar <mingo@elte.hu>:

> 
> On Mon, 28 Jul 2003, Con Kolivas wrote:
> 
> > On Sun, 27 Jul 2003 23:40, Ingo Molnar wrote:
> > >  - further increase timeslice granularity
> > 
> > For a while now I've been running a 1000Hz 2.4 O(1) kernel tree that
> > uses timeslice granularity set to MIN_TIMESLICE which has stark
> > smoothness improvements in X. I've avoided promoting this idea because
> > of the theoretical drop in throughput this might cause. I've not been
> > able to see any detriment in my basic testing of this small granularity,
> > so I was curious to see what you throught was a reasonable lower limit?
> 
> it's a hard question. The 25 msecs in -G6 is probably too low.

Just another thought on that is to make sure they don't get requeued to start 
with just 2 ticks left - which would happen to all nice 0 tasks running their 
full timeslice. Here is what I'm doing in O10:

+	} else if (!((task_timeslice(p) - p->time_slice) %
+		TIMESLICE_GRANULARITY) && (p->time_slice > MIN_TIMESLICE) &&
+		(p->array == rq->active)) {

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