Con Kolivas [interview], who maintains the -ck interactivity patchset for the 2.4 kernel [story] has been maintaining a patchset against the 2.6.0-test kernel tree, also for boosting interactivity. His latest patchset, 'O14int' was released today against both the mainline 2.6.0-test2 development kernel and Andrew Morton's [interview] 2-6.0-test2-mm5 branch. Con describes it simply as "more duct tape interactivity tweaks", going on to detail the recent changes.

From: Con Kolivas
To: linux kernel mailing list
Subject: [PATCH]O14int
Date: Sat, 9 Aug 2003 01:49:25 +1000
User-Agent: KMail/1.5.3

More duck tape interactivity tweaks

Changes

Put some bounds on the interactive_credit and specified a size beyond which a 
task is considered highly interactive or not.

Moved the uninterruptible sleep limiting to within recalc_task_prio removing 
one call of the sched_clock() and being more careful about the limits.

Wli pointed out an error in the nanosecond to jiffy conversion which may have 
been causing too easy to migrate tasks on smp (? performance change).

Put greater limitation on the requeuing code; now it only requeues interactive 
tasks thereby letting cpu hogs run their full timeslice unabated which should 
improve cpu intensive task performance.

Made highly interactive tasks earn all their waiting time on the runqueue
during requeuing as sleep_avg.

Patch applies onto 2.6.0-test2-mm5

http://kernel.kolivas.org/2.5
has the patch and a full patch against 2.6.0-test2

Patch O13.1-O14int:

[patch]


From: Timothy Miller
Subject: Re: [PATCH]O14int
Date: Fri, 08 Aug 2003 13:57:01 -0400

Con Kolivas wrote:

> Made highly interactive tasks earn all their waiting time on the runqueue
> during requeuing as sleep_avg.

There are some mechanics of this that I am not familiar with, so please 
excuse the naive question.

Someone had suggested that a task's sleep time should be determine 
exclusively from the time it spends blocked by what it's waiting on, and 
not based on any OTHER time it sleeps.  That is, the time between the 
I/O request being satisfied and the task actually getting the CPU 
doesn't count.

Is your statement above a reflection of that suggestion?



From: Con Kolivas
Subject: Re: [PATCH]O14int
Date: Sat, 9 Aug 2003 10:44:16 +1000

On Sat, 9 Aug 2003 03:57, Timothy Miller wrote:
> Con Kolivas wrote:
> > Made highly interactive tasks earn all their waiting time on the runqueue
> > during requeuing as sleep_avg.
>
> There are some mechanics of this that I am not familiar with, so please
> excuse the naive question.
>
> Someone had suggested that a task's sleep time should be determine
> exclusively from the time it spends blocked by what it's waiting on, and
> not based on any OTHER time it sleeps.  That is, the time between the
> I/O request being satisfied and the task actually getting the CPU
> doesn't count.
>
> Is your statement above a reflection of that suggestion?

I have already been doing this in previous iterations to the extent that it 
was capable of being done. There's only so much information feeding into the 
scheduler at the moment. All the dependent subsections would have to have 
more code to have specific feedback to the scheduler.

Con



From: Felipe Alfaro Solana
Subject: Re: [PATCH]O14int
Date: Fri, 08 Aug 2003 21:31:57 +0200

On Fri, 2003-08-08 at 17:49, Con Kolivas wrote:
> More duck tape interactivity tweaks
> 
> Changes
> 
> Put some bounds on the interactive_credit and specified a size beyond which a 
> task is considered highly interactive or not.
> 
> Moved the uninterruptible sleep limiting to within recalc_task_prio removing 
> one call of the sched_clock() and being more careful about the limits.
> 
> Wli pointed out an error in the nanosecond to jiffy conversion which may have 
> been causing too easy to migrate tasks on smp (? performance change).
> 
> Put greater limitation on the requeuing code; now it only requeues interactive 
> tasks thereby letting cpu hogs run their full timeslice unabated which should 
> improve cpu intensive task performance.
> 
> Made highly interactive tasks earn all their waiting time on the runqueue
> during requeuing as sleep_avg.

I have been testing this jewel on top of 2.6.0-test2-mm5 for a couple of
hours. It behaves much like O13*int, well maybe a little bit better:
Renicing X to -20 is a total disaster (sluggish window movement, Juk
skipping like mad, etc), but with X at +0 the system feels pretty good.

Evolution still feels like a mamooth when moving windows over it. XMMS
doesn't skip, neither Juk does when X is at +0. This is good :-)
All in all, this one feels good!

PS: May I say O10int is still a little bit smoother than this one? ;-)



From: Con Kolivas
Subject: Re: [PATCH]O14int
Date: Sat, 9 Aug 2003 19:04:19 +1000

On Sat, 9 Aug 2003 01:49, Con Kolivas wrote:
> More duck tape interactivity tweaks

s/duck/duct

> Wli pointed out an error in the nanosecond to jiffy conversion which may
> have been causing too easy to migrate tasks on smp (? performance change).

Looks like I broke SMP build with this. Will fix soon; don't bother trying 
this on SMP yet.

Con

From: Voluspa
Subject: Re: [PATCH]O14int
Date: Fri, 8 Aug 2003 22:08:21 +0200

On 2003-08-08 15:49:25 Con Kolivas wrote:

> More duck tape interactivity tweaks

Do you have a premonition... Game-test goes down in flames. Volatile to
the extent where I can't catch head or tail. It can behave like in
A3-O12.2 or as an unpatched 2.6.0-test2. Trigger badness by switching to
a text console. Sometimes it recovers, sometimes not. Sometimes fast,
sometimes slowly (when it does recover).

I'll withdraw under my rock now. Won't come forth until everything
smells of roses. Getting stressed by being a bringer of bad news only.
Please speak up, all you other testers. Divide the burden. Even out the
scores.

Greetings,
Mats Johannesson



From: Con Kolivas
Subject: Re: [PATCH]O14int
Date: Sat, 9 Aug 2003 10:36:17 +1000

On Sat, 9 Aug 2003 06:08, Voluspa wrote:
> On 2003-08-08 15:49:25 Con Kolivas wrote:
> > More duck tape interactivity tweaks
>
> Do you have a premonition... Game-test goes down in flames. Volatile to
> the extent where I can't catch head or tail. It can behave like in
> A3-O12.2 or as an unpatched 2.6.0-test2. Trigger badness by switching to
> a text console. 

Ah. There's the answer. You've totally changed the behaviour of the 
application in question by moving to the text console. No longer is it the 
sizable cpu hog that it is when it's in the foreground on X, so you've 
totally changed it's behaviour and how it is treated.

> Sometimes it recovers, sometimes not. Sometimes fast, 
> sometimes slowly (when it does recover).

Depends on whether the scheduler has decided firmly "you're interactive or 
not". 

Your question of course is can this be changed? Well of course everything 
_can_ be... It may be simple tuning. In the meantime the answer is don't 
switch to the text console. (Doc it hurts when I do this... Well don't do 
that). Might be useful for you to see how long it has run when it recovers, 
and how long when it no longer recovers.

> I'll withdraw under my rock now. Won't come forth until everything
> smells of roses. Getting stressed by being a bringer of bad news only.
> Please speak up, all you other testers. Divide the burden. Even out the
> scores.

Wine, women and song^H^H^H games and scheduling are not a good mix. It's not 
your fault. Please do not hold back any reports.

Con

• Archive of above thread
• KernelTrap interview with Con Kolivas
• KernelTrap interview with Andrew Morton