patch-O1int-0306281420 for 2.5.73 interactivity

patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

[-- Attachment #1: clearsigned data --]
[-- Type: Text/Plain, Size: 1885 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For my sins I've included what I thought was necessary for this patch. 

The interactivity for tasks is based on the sleep avg accumulated divided by 
the running time of the task. However since the accumulated time is not 
linear with time it now works on the premise that running time is an 
exponential function entirely. Pat Erley was the genius who implemented this 
simple exponential function in surprisingly low overhead integer maths.

Also added was some jiffy wrap logic (as if anyone would still be running my 
patch in 50 days :P).

Long sleepers were reclassified as idle according to the new exponential 
logic.

If you test, please note this works better at 1000Hz.

Attached also is my bastardised version of Ingo's timeslice granularity patch. 
This round robins tasks on the active array every 10ms, which _might_ be 
detrimental in throughput applications but has not been benchmarked. However 
for desktops it does wonders to smoothing out the jerkiness of X and I highly 
recommend using this in combination with the O1int patch.

This is very close to all the logic I wanted to implement. It might need more 
tuning... Note parent penalty, child penalty and exit weight (uppercase) no 
longer do anything.

Please test and comment.

Con

P.S. In the words of Zwane - there is always a corner case. Corner case I 
think I still need to tackle is the application that spins madly waiting for 
it's child to start, and in the process it is the parent that is starving the 
child by being higher priority than it. This seems to be a coding style 
anomaly brought out by the scheduler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+/SSSF6dfvkL3i1gRArK1AJ93sHl+I8J0qaOesShdJLvU1YENPgCglJhv
mxFcs8sAun1QNw0gz2tLJ2Q=
=S5PH
-----END PGP SIGNATURE-----

[-- Attachment #2: patch-O1int-0306281420 --]
[-- Type: text/x-diff, Size: 3867 bytes --]

diff -Naurp linux-2.5.73/include/linux/sched.h linux-2.5.73-test/include/linux/sched.h
--- linux-2.5.73/include/linux/sched.h	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/include/linux/sched.h	2003-06-28 14:09:08.000000000 +1000
@@ -336,6 +336,7 @@ struct task_struct {
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
+	unsigned long avg_start;
 	unsigned long last_run;
 
 	unsigned long policy;
diff -Naurp linux-2.5.73/kernel/fork.c linux-2.5.73-test/kernel/fork.c
--- linux-2.5.73/kernel/fork.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/fork.c	2003-06-28 14:09:08.000000000 +1000
@@ -863,6 +863,7 @@ struct task_struct *copy_process(unsigne
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = get_jiffies_64();
+	p->avg_start = jiffies;
 	p->security = NULL;
 
 	retval = -ENOMEM;
diff -Naurp linux-2.5.73/kernel/sched.c linux-2.5.73-test/kernel/sched.c
--- linux-2.5.73/kernel/sched.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/sched.c	2003-06-28 14:19:03.000000000 +1000
@@ -314,11 +314,29 @@ static inline void enqueue_task(struct t
 static int effective_prio(task_t *p)
 {
 	int bonus, prio;
+	long sleep_period, tau;
 
 	if (rt_task(p))
 		return p->prio;
 
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/MAX_SLEEP_AVG/100 -
+	tau = MAX_SLEEP_AVG;
+
+	sleep_period = jiffies - p->avg_start;
+	if (sleep_period > MAX_SLEEP_AVG)
+		sleep_period = MAX_SLEEP_AVG;
+	else if (!sleep_period)
+		return p->static_prio;
+	else {
+		sleep_period = (sleep_period *
+			17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
+		if (!sleep_period)
+			return p->static_prio;
+	}
+
+	if (p->sleep_avg > sleep_period)
+		sleep_period = p->sleep_avg;
+
+	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
 			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
@@ -349,8 +367,12 @@ static inline void activate_task(task_t 
 	long sleep_time = jiffies - p->last_run - 1;
 
 	if (sleep_time > 0) {
-		int sleep_avg;
 
+		if (sleep_time > HZ){
+			p->avg_start = jiffies - HZ;
+			p->sleep_avg = HZ / 13;
+		}
+		else {
 		/*
 		 * This code gives a bonus to interactive tasks.
 		 *
@@ -359,7 +381,7 @@ static inline void activate_task(task_t 
 		 * spends sleeping, the higher the average gets - and the
 		 * higher the priority boost gets as well.
 		 */
-		sleep_avg = p->sleep_avg + sleep_time;
+			p->sleep_avg += sleep_time;
 
 		/*
 		 * 'Overflow' bonus ticks go to the waker as well, so the
@@ -367,12 +389,14 @@ static inline void activate_task(task_t 
 		 * boosting tasks that are related to maximum-interactive
 		 * tasks.
 		 */
-		if (sleep_avg > MAX_SLEEP_AVG)
-			sleep_avg = MAX_SLEEP_AVG;
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
+			if (p->sleep_avg > MAX_SLEEP_AVG)
+				p->sleep_avg = MAX_SLEEP_AVG;
+		}
+		if (unlikely((jiffies - MAX_SLEEP_AVG) < p->avg_start)){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
 		}
+		p->prio = effective_prio(p);
 	}
 	__activate_task(p, rq);
 }
@@ -549,8 +573,6 @@ void wake_up_forked_process(task_t * p)
 	 * and children as well, to keep max-interactive tasks
 	 * from forking tasks that are max-interactive.
 	 */
-	current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100;
-	p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100;
 	p->prio = effective_prio(p);
 	set_task_cpu(p, smp_processor_id());
 
@@ -586,13 +608,6 @@ void sched_exit(task_t * p)
 			p->parent->time_slice = MAX_TIMESLICE;
 	}
 	local_irq_restore(flags);
-	/*
-	 * If the child was a (relative-) CPU hog then decrease
-	 * the sleep_avg of the parent as well.
-	 */
-	if (p->sleep_avg < p->parent->sleep_avg)
-		p->parent->sleep_avg = (p->parent->sleep_avg * EXIT_WEIGHT +
-			p->sleep_avg) / (EXIT_WEIGHT + 1);
 }
 
 /**

[-- Attachment #3: patch-granularity-0306271314 --]
[-- Type: text/x-diff, Size: 634 bytes --]

diff -Naurp linux-2.5.73/kernel/sched.c linux-2.5.73-test/kernel/sched.c
--- linux-2.5.73/kernel/sched.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/sched.c	2003-06-27 23:14:31.000000000 +1000
@@ -1229,7 +1229,16 @@ void scheduler_tick(int user_ticks, int 
 			enqueue_task(p, rq->expired);
 		} else
 			enqueue_task(p, rq->active);
+	} else {
+		if (!(p->time_slice % MIN_TIMESLICE) &&
+			       		(p->array == rq->active)) {
+			dequeue_task(p, rq->active);
+			set_tsk_need_resched(p);
+			p->prio = effective_prio(p);
+			enqueue_task(p, rq->active);
+		}
 	}
+
 out_unlock:
 	spin_unlock(&rq->lock);
 out:

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Sat, 28 Jun 2003 15:16, Con Kolivas wrote:
> For my sins I've included what I thought was necessary for this patch.
>
> The interactivity for tasks is based on the sleep avg accumulated divided
> by the running time of the task. However since the accumulated time is not
> linear with time it now works on the premise that running time is an
> exponential function entirely. Pat Erley was the genius who implemented
> this simple exponential function in surprisingly low overhead integer
> maths.
>
> Also added was some jiffy wrap logic (as if anyone would still be running
> my patch in 50 days :P).
>
> Long sleepers were reclassified as idle according to the new exponential
> logic.
>
> If you test, please note this works better at 1000Hz.
>
> Attached also is my bastardised version of Ingo's timeslice granularity
> patch. This round robins tasks on the active array every 10ms, which
> _might_ be detrimental in throughput applications but has not been
> benchmarked. However for desktops it does wonders to smoothing out the
> jerkiness of X and I highly recommend using this in combination with the
> O1int patch.
>
> This is very close to all the logic I wanted to implement. It might need
> more tuning... Note parent penalty, child penalty and exit weight
> (uppercase) no longer do anything.
>
> Please test and comment.
>
> Con
>
> P.S. In the words of Zwane - there is always a corner case. Corner case I
> think I still need to tackle is the application that spins madly waiting
> for it's child to start, and in the process it is the parent that is
> starving the child by being higher priority than it. This seems to be a
> coding style anomaly brought out by the scheduler.

And just for good measure here is the latest with a slight addition that helps 
X smoothness over time. It gives the sleep_avg a little headroom so it 
doesn't drop from interactive as easily with bursts of cpu activity.

Con

[-- Attachment #2: patch-O1int-0306290223 --]
[-- Type: text/x-diff, Size: 3887 bytes --]

diff -Naurp linux-2.5.73/include/linux/sched.h linux-2.5.73-test/include/linux/sched.h
--- linux-2.5.73/include/linux/sched.h	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/include/linux/sched.h	2003-06-28 14:09:08.000000000 +1000
@@ -336,6 +336,7 @@ struct task_struct {
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
+	unsigned long avg_start;
 	unsigned long last_run;
 
 	unsigned long policy;
diff -Naurp linux-2.5.73/kernel/fork.c linux-2.5.73-test/kernel/fork.c
--- linux-2.5.73/kernel/fork.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/fork.c	2003-06-28 14:09:08.000000000 +1000
@@ -863,6 +863,7 @@ struct task_struct *copy_process(unsigne
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = get_jiffies_64();
+	p->avg_start = jiffies;
 	p->security = NULL;
 
 	retval = -ENOMEM;
diff -Naurp linux-2.5.73/kernel/sched.c linux-2.5.73-test/kernel/sched.c
--- linux-2.5.73/kernel/sched.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/sched.c	2003-06-28 14:19:03.000000000 +1000
@@ -314,11 +314,29 @@ static inline void enqueue_task(struct t
 static int effective_prio(task_t *p)
 {
 	int bonus, prio;
+	long sleep_period, tau;
 
 	if (rt_task(p))
 		return p->prio;
 
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/MAX_SLEEP_AVG/100 -
+	tau = MAX_SLEEP_AVG;
+
+	sleep_period = jiffies - p->avg_start;
+	if (sleep_period > MAX_SLEEP_AVG)
+		sleep_period = MAX_SLEEP_AVG;
+	else if (!sleep_period)
+		return p->static_prio;
+	else {
+		sleep_period = (sleep_period *
+			17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
+		if (!sleep_period)
+			return p->static_prio;
+	}
+
+	if (p->sleep_avg > sleep_period)
+		sleep_period = p->sleep_avg;
+
+	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
 			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
@@ -349,8 +367,12 @@ static inline void activate_task(task_t 
 	long sleep_time = jiffies - p->last_run - 1;
 
 	if (sleep_time > 0) {
-		int sleep_avg;
 
+		if (sleep_time > HZ){
+			p->avg_start = jiffies - HZ;
+			p->sleep_avg = HZ / 13;
+		}
+		else {
 		/*
 		 * This code gives a bonus to interactive tasks.
 		 *
@@ -359,7 +381,7 @@ static inline void activate_task(task_t 
 		 * spends sleeping, the higher the average gets - and the
 		 * higher the priority boost gets as well.
 		 */
-		sleep_avg = p->sleep_avg + sleep_time;
+			p->sleep_avg += sleep_time;
 
 		/*
 		 * 'Overflow' bonus ticks go to the waker as well, so the
@@ -367,12 +389,14 @@ static inline void activate_task(task_t 
 		 * boosting tasks that are related to maximum-interactive
 		 * tasks.
 		 */
-		if (sleep_avg > MAX_SLEEP_AVG)
-			sleep_avg = MAX_SLEEP_AVG;
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
+			if (p->sleep_avg > MAX_SLEEP_AVG * 12 / 10)
+				p->sleep_avg = MAX_SLEEP_AVG * 11 / 10;
+		}
+		if (unlikely((jiffies - MAX_SLEEP_AVG) < p->avg_start)){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
 		}
+		p->prio = effective_prio(p);
 	}
 	__activate_task(p, rq);
 }
@@ -549,8 +573,6 @@ void wake_up_forked_process(task_t * p)
 	 * and children as well, to keep max-interactive tasks
 	 * from forking tasks that are max-interactive.
 	 */
-	current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100;
-	p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100;
 	p->prio = effective_prio(p);
 	set_task_cpu(p, smp_processor_id());
 
@@ -586,13 +608,6 @@ void sched_exit(task_t * p)
 			p->parent->time_slice = MAX_TIMESLICE;
 	}
 	local_irq_restore(flags);
-	/*
-	 * If the child was a (relative-) CPU hog then decrease
-	 * the sleep_avg of the parent as well.
-	 */
-	if (p->sleep_avg < p->parent->sleep_avg)
-		p->parent->sleep_avg = (p->parent->sleep_avg * EXIT_WEIGHT +
-			p->sleep_avg) / (EXIT_WEIGHT + 1);
 }
 
 /**

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Sat, 2003-06-28 at 18:30, Con Kolivas wrote:
> On Sat, 28 Jun 2003 15:16, Con Kolivas wrote:
> > For my sins I've included what I thought was necessary for this patch.
> >
> And just for good measure here is the latest with a slight addition that helps 
> X smoothness over time. It gives the sleep_avg a little headroom so it 
> doesn't drop from interactive as easily with bursts of cpu activity.

Have not tried this one, but previous had the same issues on this HT
box.  Reverted the two patches, and I have no mouse jerkyness or laggy
redraw of windows.

Anyhow, will it be a wise move to try and get a scheduler that works
fine for both UP and SMP ?


Regards,

-- 

Martin Schlemmer



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

On Sun, 29 Jun 2003 03:22, Martin Schlemmer wrote:
> On Sat, 2003-06-28 at 18:30, Con Kolivas wrote:
> > On Sat, 28 Jun 2003 15:16, Con Kolivas wrote:
> > > For my sins I've included what I thought was necessary for this patch.
> >
> > And just for good measure here is the latest with a slight addition that
> > helps X smoothness over time. It gives the sleep_avg a little headroom so
> > it doesn't drop from interactive as easily with bursts of cpu activity.
>
> Have not tried this one, but previous had the same issues on this HT
> box.  Reverted the two patches, and I have no mouse jerkyness or laggy
> redraw of windows.
>
> Anyhow, will it be a wise move to try and get a scheduler that works
> fine for both UP and SMP ?

Indeed. I wasn't trying to make a UP only patch, and it was not finished 
(nothing ever is really).

Con

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Felipe Alfaro Solana]

On Sat, 2003-06-28 at 18:30, Con Kolivas wrote:
> On Sat, 28 Jun 2003 15:16, Con Kolivas wrote:
> > For my sins I've included what I thought was necessary for this patch.
> >
> > The interactivity for tasks is based on the sleep avg accumulated divided
> > by the running time of the task. However since the accumulated time is not
> > linear with time it now works on the premise that running time is an
> > exponential function entirely. Pat Erley was the genius who implemented
> > this simple exponential function in surprisingly low overhead integer
> > maths.
> >
> > Also added was some jiffy wrap logic (as if anyone would still be running
> > my patch in 50 days :P).
> >
> > Long sleepers were reclassified as idle according to the new exponential
> > logic.
> >
> > If you test, please note this works better at 1000Hz.
> >
> > Attached also is my bastardised version of Ingo's timeslice granularity
> > patch. This round robins tasks on the active array every 10ms, which
> > _might_ be detrimental in throughput applications but has not been
> > benchmarked. However for desktops it does wonders to smoothing out the
> > jerkiness of X and I highly recommend using this in combination with the
> > O1int patch.
> >
> > This is very close to all the logic I wanted to implement. It might need
> > more tuning... Note parent penalty, child penalty and exit weight
> > (uppercase) no longer do anything.
> >
> > Please test and comment.
> >
> > Con
> >
> > P.S. In the words of Zwane - there is always a corner case. Corner case I
> > think I still need to tackle is the application that spins madly waiting
> > for it's child to start, and in the process it is the parent that is
> > starving the child by being higher priority than it. This seems to be a
> > coding style anomaly brought out by the scheduler.
> 
> And just for good measure here is the latest with a slight addition that helps 
> X smoothness over time. It gives the sleep_avg a little headroom so it 
> doesn't drop from interactive as easily with bursts of cpu activity.

OK, now testing this one :-)
2.5.73-mm2 + latest patch-O1int + patch-granularity + 1000HZ...
Feels a little bit better than the previous one. X under load is
smoother. This is starting to get interesting ;-)

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Felipe Alfaro Solana]

On Sat, 2003-06-28 at 07:16, Con Kolivas wrote:
> The interactivity for tasks is based on the sleep avg accumulated divided by 
> the running time of the task. However since the accumulated time is not 
> linear with time it now works on the premise that running time is an 
> exponential function entirely. Pat Erley was the genius who implemented this 
> simple exponential function in surprisingly low overhead integer maths.
> 
> Also added was some jiffy wrap logic (as if anyone would still be running my 
> patch in 50 days :P).
> 
> Long sleepers were reclassified as idle according to the new exponential 
> logic.
> 
> If you test, please note this works better at 1000Hz.

Currently testing on 2.5.73-mm2, with both patches (patch-O1int and
patch-granularity) plus HZ=1000. The result is quite impressive. Under
load, X still suffer a little lag and behaves a little worse than the
combo patch from Mike Galbraith + Ingo, but now XMMS doesn't skip even
when clicking a link inside Evolution.

Please, let me more time to work with this new patched kernel a little
bit more to see if I can find any strange issues.

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[pat erley]

I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.  

what it says right now:

/kernel/sched.c around line 325


sleep_period = (sleep_period *
	17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
----------------------------------------------------------^

it should be:

sleep_period = (sleep_period *
	17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
--------------------------------------------------------------^

stupid parenthesis.

a little background.  what this essentially is is a taylor approximation of the function ln(66x+1) normalized.  ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.

Pat
-- 

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Roberto Orenstein]

On Sat, 2003-06-28 at 17:26, pat erley wrote:
> I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.  
> 
> what it says right now:
> 
> /kernel/sched.c around line 325
> 
> 
> sleep_period = (sleep_period *
> 	17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
> ----------------------------------------------------------^
> 
> it should be:
> 
> sleep_period = (sleep_period *
> 	17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
> --------------------------------------------------------------^
> 
> stupid parenthesis.
> 
> a little background.  what this essentially is is a taylor approximation of the function ln(66x+1) normalized.  ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.
> 
> Pat

I did your correction and I got a kernel panic(attempting to kill init)
on boot. It didn't flushed to disk, so it isn't attached, but it panics
at effective_prio+0xcc/0xe0.
With objdump I could see it traps a division by 0: 
cc:       f7 fb                   idiv   %ebx

I remember cleary %ebx being 0 on the panic report.
And I tracked down and the code is on this else in effective_prio:
----------- sched.c 341-----------------
else {
	sleep_period = (sleep_period *
		17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
	if (!sleep_period)
		return p->static_prio;
	}
--------------------------------------

I don't have the time now to track this further today, but what happens
if sleep_period is too small and tau is too big?
 Could this (17 * sleep_period / (5 * tau + 2) give 0 and so a division
by 0?

abs
Roberto

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

On Sun, 29 Jun 2003 08:45, Roberto Orenstein wrote:
> On Sat, 2003-06-28 at 17:26, pat erley wrote:
> > I made a small error when I sent Con a piece of magic I wrote up to help
> > the sleep period.
> >
> > what it says right now:
> >
> > /kernel/sched.c around line 325
> >
> >
> > sleep_period = (sleep_period *
> > 	17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
> > ----------------------------------------------------------^
> >
> > it should be:
> >
> > sleep_period = (sleep_period *
> > 	17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
> > --------------------------------------------------------------^
> >
> > stupid parenthesis.
> >
> > a little background.  what this essentially is is a taylor approximation
> > of the function ln(66x+1) normalized.  ln(66x+1) happens to do a great
> > job oas a weighting function on the range of 0 to 1, and because the
> > input only happens to range from 0 to 1, only 2 terms were needed to do a
> > 'good enough' job.
> >
> > Pat
>
> I did your correction and I got a kernel panic(attempting to kill init)
> on boot. It didn't flushed to disk, so it isn't attached, but it panics
> at effective_prio+0xcc/0xe0.
> With objdump I could see it traps a division by 0:
> cc:       f7 fb                   idiv   %ebx
>
> I remember cleary %ebx being 0 on the panic report.
> And I tracked down and the code is on this else in effective_prio:
> ----------- sched.c 341-----------------
> else {
> 	sleep_period = (sleep_period *
> 		17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
> 	if (!sleep_period)
> 		return p->static_prio;
> 	}
> --------------------------------------
>
> I don't have the time now to track this further today, but what happens
> if sleep_period is too small and tau is too big?
>  Could this (17 * sleep_period / (5 * tau + 2) give 0 and so a division
> by 0?

This will give a divide by zero.

I will put together a new patch soon with this correction and appropriate 
logic.

Con

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

On Sun, 29 Jun 2003 11:32, Con Kolivas wrote:
> On Sun, 29 Jun 2003 08:45, Roberto Orenstein wrote:
> > On Sat, 2003-06-28 at 17:26, pat erley wrote:
> > > I made a small error when I sent Con a piece of magic I wrote up to
> > > help the sleep period.
> > >
> > > what it says right now:
> > >
> > > /kernel/sched.c around line 325
> > >
> > >
> > > sleep_period = (sleep_period *
> > > 	17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
> > > ----------------------------------------------------------^
> > >
> > > it should be:
> > >
> > > sleep_period = (sleep_period *
> > > 	17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
> > > --------------------------------------------------------------^
> > >
> > > stupid parenthesis.
> > >
> > > a little background.  what this essentially is is a taylor
> > > approximation of the function ln(66x+1) normalized.  ln(66x+1) happens
> > > to do a great job oas a weighting function on the range of 0 to 1, and
> > > because the input only happens to range from 0 to 1, only 2 terms were
> > > needed to do a 'good enough' job.
> > >
> > > Pat
> >
> > I did your correction and I got a kernel panic(attempting to kill init)
> > on boot. It didn't flushed to disk, so it isn't attached, but it panics
> > at effective_prio+0xcc/0xe0.
> > With objdump I could see it traps a division by 0:
> > cc:       f7 fb                   idiv   %ebx
> >
> > I remember cleary %ebx being 0 on the panic report.
> > And I tracked down and the code is on this else in effective_prio:
> > ----------- sched.c 341-----------------
> > else {
> > 	sleep_period = (sleep_period *
> > 		17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
> > 	if (!sleep_period)
> > 		return p->static_prio;
> > 	}
> > --------------------------------------
> >
> > I don't have the time now to track this further today, but what happens
> > if sleep_period is too small and tau is too big?
> >  Could this (17 * sleep_period / (5 * tau + 2) give 0 and so a division
> > by 0?
>
> This will give a divide by zero.
>
> I will put together a new patch soon with this correction and appropriate
> logic.

Further inspection of this code shows to me that the current version will do 
the job adequately. The full function Pat put together is a little more 
complicated and unfortunately falls over with integer logic. This one is a 
reasonable enough approximation.

So to summarise, if you still wish to test/use this patch, continue using the 
patch as posted unmodified called:

patch-O1int-0306290223

Con

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Summary:
A patch to reduce audio skipping and X jerking under load.

It's looking seriously like I'm talking to myelf here, but just in case there 
are lurkers testing this patch, there's a big bug that made it think jiffy 
wraparound was occurring so interactive tasks weren't receiving the boost 
they deserved. Here is a patch with the fix in. 

How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing 
X off. 

Con

[-- Attachment #2: patch-O1int-0306301522 --]
[-- Type: text/x-diff, Size: 3869 bytes --]

diff -Naurp linux-2.5.73/include/linux/sched.h linux-2.5.73-test/include/linux/sched.h
--- linux-2.5.73/include/linux/sched.h	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/include/linux/sched.h	2003-06-28 14:09:08.000000000 +1000
@@ -336,6 +336,7 @@ struct task_struct {
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
+	unsigned long avg_start;
 	unsigned long last_run;
 
 	unsigned long policy;
diff -Naurp linux-2.5.73/kernel/fork.c linux-2.5.73-test/kernel/fork.c
--- linux-2.5.73/kernel/fork.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/fork.c	2003-06-28 14:09:08.000000000 +1000
@@ -863,6 +863,7 @@ struct task_struct *copy_process(unsigne
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = get_jiffies_64();
+	p->avg_start = jiffies;
 	p->security = NULL;
 
 	retval = -ENOMEM;
diff -Naurp linux-2.5.73/kernel/sched.c linux-2.5.73-test/kernel/sched.c
--- linux-2.5.73/kernel/sched.c	2003-06-26 01:30:42.000000000 +1000
+++ linux-2.5.73-test/kernel/sched.c	2003-06-28 14:19:03.000000000 +1000
@@ -314,11 +314,29 @@ static inline void enqueue_task(struct t
 static int effective_prio(task_t *p)
 {
 	int bonus, prio;
+	long sleep_period, tau;
 
 	if (rt_task(p))
 		return p->prio;
 
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/MAX_SLEEP_AVG/100 -
+	tau = MAX_SLEEP_AVG;
+
+	sleep_period = jiffies - p->avg_start;
+	if (sleep_period > MAX_SLEEP_AVG)
+		sleep_period = MAX_SLEEP_AVG;
+	else if (!sleep_period)
+		return p->static_prio;
+	else {
+		sleep_period = (sleep_period *
+			17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
+		if (!sleep_period)
+			return p->static_prio;
+	}
+
+	if (p->sleep_avg > sleep_period)
+		sleep_period = p->sleep_avg;
+
+	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
 			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
@@ -349,8 +367,12 @@ static inline void activate_task(task_t 
 	long sleep_time = jiffies - p->last_run - 1;
 
 	if (sleep_time > 0) {
-		int sleep_avg;
 
+		if (sleep_time > HZ){
+			p->avg_start = jiffies - HZ;
+			p->sleep_avg = HZ / 13;
+		}
+		else {
 		/*
 		 * This code gives a bonus to interactive tasks.
 		 *
@@ -359,7 +381,7 @@ static inline void activate_task(task_t 
 		 * spends sleeping, the higher the average gets - and the
 		 * higher the priority boost gets as well.
 		 */
-		sleep_avg = p->sleep_avg + sleep_time;
+			p->sleep_avg += sleep_time;
 
 		/*
 		 * 'Overflow' bonus ticks go to the waker as well, so the
@@ -367,12 +389,14 @@ static inline void activate_task(task_t 
 		 * boosting tasks that are related to maximum-interactive
 		 * tasks.
 		 */
-		if (sleep_avg > MAX_SLEEP_AVG)
-			sleep_avg = MAX_SLEEP_AVG;
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
+			if (p->sleep_avg > MAX_SLEEP_AVG * 12 / 10)
+				p->sleep_avg = MAX_SLEEP_AVG * 11 / 10;
+		}
+		if (unlikely(p->avg_start > jiffies)){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
 		}
+		p->prio = effective_prio(p);
 	}
 	__activate_task(p, rq);
 }
@@ -549,8 +573,6 @@ void wake_up_forked_process(task_t * p)
 	 * and children as well, to keep max-interactive tasks
 	 * from forking tasks that are max-interactive.
 	 */
-	current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100;
-	p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100;
 	p->prio = effective_prio(p);
 	set_task_cpu(p, smp_processor_id());
 
@@ -586,13 +608,6 @@ void sched_exit(task_t * p)
 			p->parent->time_slice = MAX_TIMESLICE;
 	}
 	local_irq_restore(flags);
-	/*
-	 * If the child was a (relative-) CPU hog then decrease
-	 * the sleep_avg of the parent as well.
-	 */
-	if (p->sleep_avg < p->parent->sleep_avg)
-		p->parent->sleep_avg = (p->parent->sleep_avg * EXIT_WEIGHT +
-			p->sleep_avg) / (EXIT_WEIGHT + 1);
 }
 
 /**

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Andrew Morton]

Con Kolivas <kernel@kolivas.org> wrote:
>
> It's looking seriously like I'm talking to myelf here

Let me know when it is sufficiently cooked and I'll give it a run
in -mm.

We obviously have issues in there still, and it is good that you
guys are working it.

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Mike Galbraith]

Greetings,

At 03:35 PM 6/30/2003 +1000, Con Kolivas wrote:
>Summary:
>A patch to reduce audio skipping and X jerking under load.

I took it out for a quick spin.  It kills thud graveyard dead.  That's the 
good news, now for the bad ;-)  With a make -j5 running, kasteroids 
stutters enough to be pretty annoying.  The patched kernel is making 
booboos wrt cc1's priority often enough to nail kasteroids pretty 
hard.  The mouse pointer also jerks around quite a bit,...

>It's looking seriously like I'm talking to myelf here, but just in case there
>are lurkers testing this patch, there's a big bug that made it think jiffy
>wraparound was occurring so interactive tasks weren't receiving the boost
>they deserved. Here is a patch with the fix in.
>
>How to use if you're still thinking of testing:
>Use with Hz 1000, and use the granularity patch I posted as well for 
>smoothing
>X off.

...but I'm not using that, because I wanted to see the pure effects of this 
patch.

         -Mike

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

On Mon, 30 Jun 2003 17:57, Mike Galbraith wrote:
> Greetings,
>
> At 03:35 PM 6/30/2003 +1000, Con Kolivas wrote:
> >Summary:
> >A patch to reduce audio skipping and X jerking under load.
>
> I took it out for a quick spin.  It kills thud graveyard dead.  That's the
> good news, now for the bad ;-)  With a make -j5 running, kasteroids
> stutters enough to be pretty annoying.  The patched kernel is making
> booboos wrt cc1's priority often enough to nail kasteroids pretty
> hard.  The mouse pointer also jerks around quite a bit,...

Consider it not optimised yet. The workings are still evolving but are now 
close. It errs on the too-easy to get a bonus in the early ms after an app 
has started at the moment.

>
> >It's looking seriously like I'm talking to myelf here, but just in case
> > there are lurkers testing this patch, there's a big bug that made it
> > think jiffy wraparound was occurring so interactive tasks weren't
> > receiving the boost they deserved. Here is a patch with the fix in.
> >
> >How to use if you're still thinking of testing:
> >Use with Hz 1000, and use the granularity patch I posted as well for
> >smoothing
> >X off.
>
> ...but I'm not using that, because I wanted to see the pure effects of this
> patch.

Good point. If it's going to be developed properly it should only include what 
is likely to be used with it.

Con

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Mike Galbraith]

At 08:16 PM 6/30/2003 +1000, Con Kolivas wrote:

>Consider it not optimised yet. The workings are still evolving but are now
>close. It errs on the too-easy to get a bonus in the early ms after an app
>has started at the moment.

Yeah, that's the way it looks from here too.  It's getting it right more 
often than wrong, that's encouraging.

         -Mike 

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Felipe Alfaro Solana]

On Mon, 2003-06-30 at 07:35, Con Kolivas wrote:

> A patch to reduce audio skipping and X jerking under load.

Can't make XMMS skip audio with "while true; do a = 2; done" while
playing moving windows under an X session.

> It's looking seriously like I'm talking to myelf here, but just in case there 
> are lurkers testing this patch, there's a big bug that made it think jiffy 
> wraparound was occurring so interactive tasks weren't receiving the boost 
> they deserved. Here is a patch with the fix in. 

Well, you're not talking to yourself. We're listening and testing:
2.5.73-mm2 + patch-O1int + patch-granularity + patch-1000HZ. With this
new version of the patch, the mouse cursor jumpiness has returned again,
altough in much less extent than in previous versions: it's more
difficult to reproduce, but it's present just when logging onto my KDE
session on a Red Hat Linux 9 box. For the rest of the session, it's
pretty hard difficult to make the mouse cursor to turn jumpy.

> How to use if you're still thinking of testing:
> Use with Hz 1000, and use the granularity patch I posted as well for smoothing 
> X off. 

Under heavy load (3 simulatenous consoles doing while true; do a=2;
done), X feels smooth, but moving windows aggresively, makes X go jerky
for a few seconds and some process do starve a little when repainting.

Anyways, at a first glance, it looks really good :-)

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Marc-Christian Petersen]

On Monday 30 June 2003 07:35, Con Kolivas wrote:

Hi Con,

> A patch to reduce audio skipping and X jerking under load.
> It's looking seriously like I'm talking to myelf here, but just in case
> there are lurkers testing this patch, there's a big bug that made it think
> jiffy wraparound was occurring so interactive tasks weren't receiving the
> boost they deserved. Here is a patch with the fix in.
> How to use if you're still thinking of testing:
> Use with Hz 1000, and use the granularity patch I posted as well for
> smoothing X off.
using 2.5.73-mm2, 1000HZ, patch-O1int-0306301522, patch-granularity-0306271314

"make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily, X is 
not very smooth, mouse jumps, X is sometimes not accepting anything for 5-10 
seconds every 1-2 minutes, everything freezes, also XMMS, Kmail freezes, an 
Xterm needs ~40 seconds to open. If the machine is totally idle, Kmail 
freezes also for ~5 seconds. Tried running X with 0, -1 and -11 w/o much 
difference.

I still like Felipe's O(1) patch.

Machine: Celeron 1,3GHz, 512MB RAM, 512MB SWAP, IDE (UDMA100), ext3fs, X4.3, 
WindowMaker.

Please, can we invite Ingo to this thread? I think it is now _really_ the time 
to get this fixed up :)

ciao, Marc

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Andrew Morton]

Marc-Christian Petersen <m.c.p@wolk-project.de> wrote:
>
>  "make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily

Well it would.   Try not to do that.  We shouldn't optimise
for things which basically nobody would do.

`make -j2' would be more interesting.  

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Marc-Christian Petersen]

On Monday 30 June 2003 11:47, Andrew Morton wrote:

Hi Andrew,

> >  "make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily
> Well it would.   Try not to do that.  We shouldn't optimise
> for things which basically nobody would do.
> `make -j2' would be more interesting.
Well, it shouldn't *imho*. And it is possible. Currently I am running 
2.4.20-wolk4.3 and I do "make -j32 bzImage modules" and I cannot make XMMS 
skip doesn't matter what I do, it is not possible. Even X is smooth, kmail 
does not freeze, an Xterm needs ~4 seconds to open.

My tree uses the O(1) from Andrea including the fixes.

Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned 
patches. Three skips during the whole compilation (bzImage modules).

ciao, Marc

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Andrew Morton]

Marc-Christian Petersen <m.c.p@wolk-project.de> wrote:
>
> Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned 
>  patches. Three skips during the whole compilation (bzImage modules).

And what happens without the scheduler patches?

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Marc-Christian Petersen]

On Monday 30 June 2003 12:17, Andrew Morton wrote:

Hi Andrew,

> > Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned
> >  patches. Three skips during the whole compilation (bzImage modules).
> And what happens without the scheduler patches?
Not countable XMMS skips (read: too many)

ciao, Marc

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Mike Galbraith]

At 11:39 AM 6/30/2003 +0200, Marc-Christian Petersen wrote:

>Please, can we invite Ingo to this thread? I think it is now _really_ the 
>time
>to get this fixed up :)

The giants all seem to be busy... are munchkins stackable? ;-) 

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]


>At 11:39 AM 6/30/2003 +0200, Marc-Christian Petersen wrote:
>>Please, can we invite Ingo to this thread? I think it is now _really_ the
>>time
>>to get this fixed up :)
>
>The giants all seem to be busy... are munchkins stackable? ;-)

Ok this munchkin has some more to contribute.

Here is the next patch which shows a large improvement. Gone is the 
unnecessary exponential function (sorry Pat it was fun), and now the patch 
will start calculating interactivity from the first time an application is 
activated.

This takes away the X jerkiness evident in the previous patches (yes I do 
believe you MCP). No granularity patch is needed either.

Please test the bejeesus out of this one; MCP your test case is the most 
valuable.

Con



[-- Attachment #2: patch-O1int-0306302317 --]
[-- Type: text/x-diff, Size: 3532 bytes --]

--- linux-2.5.73/kernel/sched.c	2003-06-30 10:06:40.000000000 +1000
+++ linux-2.5.73-test/kernel/sched.c	2003-06-30 23:16:42.000000000 +1000
@@ -314,11 +314,23 @@ static inline void enqueue_task(struct t
 static int effective_prio(task_t *p)
 {
 	int bonus, prio;
+	long sleep_period;

 	if (rt_task(p))
 		return p->prio;

-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/MAX_SLEEP_AVG/100 -
+	sleep_period = jiffies - p->avg_start;
+
+	if (!sleep_period)
+		return p->static_prio;
+
+	if (sleep_period > MAX_SLEEP_AVG)
+		sleep_period = MAX_SLEEP_AVG;
+
+	if (p->sleep_avg > sleep_period)
+		sleep_period = p->sleep_avg;
+
+	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
 			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;

 	prio = p->static_prio - bonus;
@@ -348,9 +360,19 @@ static inline void activate_task(task_t
 {
 	long sleep_time = jiffies - p->last_run - 1;

-	if (sleep_time > 0) {
-		int sleep_avg;
+	if (p->avg_start == 0){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
+			sleep_time = 0;
+	}

+	if (sleep_time >= 0) {
+
+		if (sleep_time > HZ){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
+		}
+		else {
 		/*
 		 * This code gives a bonus to interactive tasks.
 		 *
@@ -359,7 +381,7 @@ static inline void activate_task(task_t
 		 * spends sleeping, the higher the average gets - and the
 		 * higher the priority boost gets as well.
 		 */
-		sleep_avg = p->sleep_avg + sleep_time;
+			p->sleep_avg += sleep_time;

 		/*
 		 * 'Overflow' bonus ticks go to the waker as well, so the
@@ -367,12 +389,14 @@ static inline void activate_task(task_t
 		 * boosting tasks that are related to maximum-interactive
 		 * tasks.
 		 */
-		if (sleep_avg > MAX_SLEEP_AVG)
-			sleep_avg = MAX_SLEEP_AVG;
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
+			if (p->sleep_avg > MAX_SLEEP_AVG * 12/10)
+				p->sleep_avg = MAX_SLEEP_AVG * 11/10;
+		}
+		if (unlikely(p->avg_start > jiffies)){
+			p->avg_start = jiffies;
+			p->sleep_avg = 0;
 		}
+		p->prio = effective_prio(p);
 	}
 	__activate_task(p, rq);
 }
@@ -549,8 +573,6 @@ void wake_up_forked_process(task_t * p)
 	 * and children as well, to keep max-interactive tasks
 	 * from forking tasks that are max-interactive.
 	 */
-	current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100;
-	p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100;
 	p->prio = effective_prio(p);
 	set_task_cpu(p, smp_processor_id());

@@ -586,13 +608,6 @@ void sched_exit(task_t * p)
 			p->parent->time_slice = MAX_TIMESLICE;
 	}
 	local_irq_restore(flags);
-	/*
-	 * If the child was a (relative-) CPU hog then decrease
-	 * the sleep_avg of the parent as well.
-	 */
-	if (p->sleep_avg < p->parent->sleep_avg)
-		p->parent->sleep_avg = (p->parent->sleep_avg * EXIT_WEIGHT +
-			p->sleep_avg) / (EXIT_WEIGHT + 1);
 }

 /**
--- linux-2.5.73/kernel/fork.c	2003-06-30 10:06:40.000000000 +1000
+++ linux-2.5.73-test/kernel/fork.c	2003-06-30 23:06:26.000000000 +1000
@@ -863,6 +863,7 @@ struct task_struct *copy_process(unsigne
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = get_jiffies_64();
+	p->avg_start = 0;
 	p->security = NULL;

 	retval = -ENOMEM;
--- linux-2.5.73/include/linux/sched.h	2003-06-30 10:06:40.000000000 +1000
+++ linux-2.5.73-test/include/linux/sched.h	2003-06-30 13:23:46.000000000 +1000
@@ -336,6 +336,7 @@ struct task_struct {
 	prio_array_t *array;

 	unsigned long sleep_avg;
+	unsigned long avg_start;
 	unsigned long last_run;

 	unsigned long policy;

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Marc-Christian Petersen]

On Monday 30 June 2003 15:38, Con Kolivas wrote:

Moin Con,

> Ok this munchkin has some more to contribute.
hehe.

> Here is the next patch which shows a large improvement. Gone is the
> unnecessary exponential function (sorry Pat it was fun), and now the patch
> will start calculating interactivity from the first time an application is
> activated.
nice.

> This takes away the X jerkiness evident in the previous patches (yes I do
> believe you MCP). No granularity patch is needed either.
ok.

> Please test the bejeesus out of this one; MCP your test case is the most
> valuable.
tyvm :) I'll give it a try in ~30 mins.

ciao, Marc

Re: patch-O1int-0306281420 for 2.5.73 interactivity

[Davide Libenzi]

On Mon, 30 Jun 2003, Mike Galbraith wrote:

> At 11:39 AM 6/30/2003 +0200, Marc-Christian Petersen wrote:
>
> >Please, can we invite Ingo to this thread? I think it is now _really_ the
> >time
> >to get this fixed up :)
>
> The giants all seem to be busy... are munchkins stackable? ;-)

Ingo, when you come back from Mars :) ... what has been changed from the
very first versions of 2.5.x ? I was able to run unrealistic `make -j`
(among other crap) and still have a liquid desktop back then ...



- Davide