[PATCH]O19int

[PATCH]O19int

[Con Kolivas]

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

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

Small error in the just interactive logic has been corrected.

Idle tasks get one higher priority than just interactive so they don't get 
swamped under heavy load.

Cosmetic cleanup.

Patch against 2.6.0-test4-mm2

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/TumgZUg7+tp6mRURAtkkAJwJKjY1DmvuNR+eyphU07svVP7uWQCeMHgv
pcYhT1dX+iaFq6F1Son8pGc=
=rxj9
-----END PGP SIGNATURE-----

[-- Attachment #2: patch-O18.1-O19int --]
[-- Type: text/x-diff, Size: 2674 bytes --]

--- linux-2.6.0-test4-mm2/kernel/sched.c	2003-08-28 22:57:49.000000000 +1000
+++ linux-2.6.0-test4-mm2-O19/kernel/sched.c	2003-08-29 15:37:06.000000000 +1000
@@ -64,8 +64,8 @@
 /*
  * Some helpers for converting nanosecond timing to jiffy resolution
  */
-#define NS_TO_JIFFIES(TIME)	(TIME / (1000000000 / HZ))
-#define JIFFIES_TO_NS(TIME)	(TIME * (1000000000 / HZ))
+#define NS_TO_JIFFIES(TIME)	((TIME) / (1000000000 / HZ))
+#define JIFFIES_TO_NS(TIME)	((TIME) * (1000000000 / HZ))
 
 /*
  * These are the 'tuning knobs' of the scheduler:
@@ -132,7 +132,8 @@
 	((p)->prio <= (p)->static_prio - DELTA(p))
 
 #define JUST_INTERACTIVE_SLEEP(p) \
-	(MAX_SLEEP_AVG - (DELTA(p) * AVG_TIMESLICE))
+	(JIFFIES_TO_NS(MAX_SLEEP_AVG * \
+		(MAX_BONUS / 2 + DELTA((p)) + 1) / MAX_BONUS - 1))
 
 #define HIGH_CREDIT(p) \
 	((p)->interactive_credit > MAX_SLEEP_AVG)
@@ -382,10 +383,8 @@ static void recalc_task_prio(task_t *p, 
 		 * prevent them suddenly becoming cpu hogs and starving
 		 * other processes.
 		 */
-		if (p->mm && sleep_time >
-			JIFFIES_TO_NS(JUST_INTERACTIVE_SLEEP(p)))
-				p->sleep_avg =
-					JIFFIES_TO_NS(JUST_INTERACTIVE_SLEEP(p));
+		if (p->mm && sleep_time >JUST_INTERACTIVE_SLEEP(p))
+			p->sleep_avg = JUST_INTERACTIVE_SLEEP(p) + 1;
 		else {
 			/*
 			 * The lower the sleep avg a task has the more
@@ -405,16 +404,15 @@ static void recalc_task_prio(task_t *p, 
 			/*
 			 * Non high_credit tasks waking from uninterruptible
 			 * sleep are limited in their sleep_avg rise as they
-			 * are likely to be waiting on I/O
+			 * are likely to be cpu hogs waiting on I/O
 			 */
 			if (p->activated == -1 && !HIGH_CREDIT(p) && p->mm){
-				if (p->sleep_avg >=
-					JIFFIES_TO_NS(JUST_INTERACTIVE_SLEEP(p)))
-						sleep_time = 0;
+				if (p->sleep_avg >= JUST_INTERACTIVE_SLEEP(p))
+					sleep_time = 0;
 				else if (p->sleep_avg + sleep_time >=
-					JIFFIES_TO_NS(JUST_INTERACTIVE_SLEEP(p))){
+					JUST_INTERACTIVE_SLEEP(p)){
 						p->sleep_avg =
-							JIFFIES_TO_NS(JUST_INTERACTIVE_SLEEP(p));
+							JUST_INTERACTIVE_SLEEP(p);
 						sleep_time = 0;
 					}
 			}
@@ -431,7 +429,8 @@ static void recalc_task_prio(task_t *p, 
 
 			if (p->sleep_avg > NS_MAX_SLEEP_AVG){
 				p->sleep_avg = NS_MAX_SLEEP_AVG;
-				p->interactive_credit += !(HIGH_CREDIT(p));
+				if (!HIGH_CREDIT(p))
+					p->interactive_credit++;
 			}
 		}
 	}
@@ -1547,8 +1546,8 @@ switch_tasks:
 	prev->sleep_avg -= run_time;
 	if ((long)prev->sleep_avg <= 0){
 		prev->sleep_avg = 0;
-		prev->interactive_credit -=
-			!(HIGH_CREDIT(prev) || LOW_CREDIT(prev));
+		if (!(HIGH_CREDIT(prev) || LOW_CREDIT(prev)))
+			prev->interactive_credit--;
 	}
 	prev->timestamp = now;
 

Re: [PATCH]O19int

[Voluspa]

On Fri, 29 Aug 2003 15:50:22 +1000
Con Kolivas wrote:

> Patch against 2.6.0-test4-mm2

Patched the -mm2 kernel and perceive/see no regression during my usual
tests. In fact, I _believe_ the anti-starvation is even better now,
compared to O18.1

The new Blender 2.28a could be thrown into a self-starvation by altering
a few parameters in my test, resulting in the usual short freezes. And
2.28 behaved the same, although a bit harder to make it happen.

The altered test have no effect on either Blender with this O19int.

Mvh
Mats Johannesson

Re: [PATCH]O19int

[Felipe Alfaro Solana]

On Fri, 2003-08-29 at 07:50, Con Kolivas wrote:

> Small error in the just interactive logic has been corrected.
> 
> Idle tasks get one higher priority than just interactive so they don't get 
> swamped under heavy load.
> 
> Cosmetic cleanup.
> 
> Patch against 2.6.0-test4-mm2

Spectacular!
Smooth as silk and, when combined with CFQ scheduler, it's impossible to
make sound skip, even under heavy CPU and I/O load.

Re: [PATCH]O19int

[Apurva Mehta]

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

* Con Kolivas <kernel@kolivas.org> [29-08-2003 15:26]:
> Small error in the just interactive logic has been corrected.
> 
> Idle tasks get one higher priority than just interactive so they don't get 
> swamped under heavy load.
> 
> Cosmetic cleanup.
> 
> Patch against 2.6.0-test4-mm2

I am using it against 2.6.0-test4-mm3-1. I get quite severe music
skipping while scrolling a relatively light website (slashdot) on
Firebird even when there is no other load. I am attaching some of the
numbers I captured during while there was skipping going on. I am also
attaching the script I used to capture the numbers.

A long skip occured during the first few seconds of the test (while
scrolling the website). In the remaining time I opened emacs and then
switched to kghostview (which had been idle for a long time and looked
like it had to be brought out of swap ie.. there was a relatively long
delay before I could use it). The sound did not skip again.

Apart from the above incident, this patch feels better as compared to
O16.3int. 

Keep up the good work..

Regards,

	- Apurva

[-- Attachment #2: numbers.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 10502 bytes --]

[-- Attachment #3: script --]
[-- Type: text/plain, Size: 732 bytes --]

#!/bin/bash

# Linux interactivity profiler script
# requires profile=2 (or 1?) as a kernel boot param
# Script takes optional number of iterations
# param., default is 10 iterations

# reset the profiler
/usr/sbin/readprofile -r

KERN=$(uname -r)
OUT_DIR=/root/profs/

#[ -w ${OUT_DIR} ] || OUT_DIR=$(pwd)

if [ -z $1 ]; then
        ITS=10
else
        ITS=$1
fi

# Collect vmstat output
vmstat 1 ${ITS}|cat -n > ${OUT_DIR}/${KERN}-vmstat &

# Collect top output
top b d1 n${ITS} > ${OUT_DIR}/${KERN}-top &

n=1
# Collect profile
while [ ${n} -le ${ITS} ]; do

        /usr/sbin/readprofile -n -m /boot/System.map-${KERN} \
        | sort -nr -k 3,3 > ${OUT_DIR}/${KERN}-prof.${n}

        n=$(( ${n} + 1 ))

        sleep 1
done

Re: [PATCH]O19int

[Rahul Karnik]

Apurva Mehta wrote:
> I am using it against 2.6.0-test4-mm3-1. I get quite severe music
> skipping while scrolling a relatively light website (slashdot) on
> Firebird even when there is no other load.

Please specify the music player you are using. Different ones usually 
behave differently.

Thanks,
Rahul
-- 
Rahul Karnik
rahul@genebrew.com
http://www.genebrew.com/

Re: [PATCH]O19int

[Apurva Mehta]

* Rahul Karnik <rahul@genebrew.com> [29-08-2003 22:09]:
> Apurva Mehta wrote:
> >I am using it against 2.6.0-test4-mm3-1. I get quite severe music
> >skipping while scrolling a relatively light website (slashdot) on
> >Firebird even when there is no other load.
> 
> Please specify the music player you are using. Different ones usually 
> behave differently.

xmms, that is the only one I have used in all my tests..

	- Apurva

Re: [PATCH]O19int

[Maciej Soltysiak]

> Small error in the just interactive logic has been corrected.
>
> Idle tasks get one higher priority than just interactive so they don't get
> swamped under heavy load.
>
> Cosmetic cleanup.
>
> Patch against 2.6.0-test4-mm2
Hey, now that's the best desktop kernel operation I have seen.

Everything is really smooth.

Thanks!

> Con
Maciej

Re: [PATCH]O19int

[Rahul Karnik]

Somehow I can never reproduce these xmms skips, even in mainline 
kernels. I had them for a few days with older versions of rhythmbox, but 
no longer. So it seems that some of this is definitely system dependent? 
For the record, I have an Athlon XP 2100+ (1700 MHz) and 1G of memory (a 
pretty medium line desktop system), not the multi-cpu multi-gigabyte-RAM 
systems some people around here do.

Are people getting skips on hardware that is faster than this?

Thanks,
Rahul
-- 
Rahul Karnik
rahul@genebrew.com
http://www.genebrew.com/

Re: [PATCH]O19int

[Con Kolivas]

On Sat, 30 Aug 2003 03:42, Rahul Karnik wrote:
> Somehow I can never reproduce these xmms skips, even in mainline
> kernels. I had them for a few days with older versions of rhythmbox, but
> no longer. So it seems that some of this is definitely system dependent?
> For the record, I have an Athlon XP 2100+ (1700 MHz) and 1G of memory (a
> pretty medium line desktop system), not the multi-cpu multi-gigabyte-RAM
> systems some people around here do.
>
> Are people getting skips on hardware that is faster than this?

People are not getting skips on hardware significantly lower spec than this. 
The most common remaining reason for this is a misconfigured ide driver, and 
dma issues with their hard drives. Sometimes the driver name has changed 
2.4->2.6 and people using their old config dont inherit the correct driver.

Con

Re: [PATCH]O19int

[Apurva Mehta]

* Rahul Karnik <rahul@genebrew.com> [30-08-2003 20:46]:
> Somehow I can never reproduce these xmms skips, even in mainline 
> kernels. I had them for a few days with older versions of rhythmbox, but 
> no longer. So it seems that some of this is definitely system dependent? 
> For the record, I have an Athlon XP 2100+ (1700 MHz) and 1G of memory (a 
> pretty medium line desktop system), not the multi-cpu multi-gigabyte-RAM 
> systems some people around here do.
> 
> Are people getting skips on hardware that is faster than this?

Well, I have a 500 Mhz PIII and 192 MB of RAM. However, I never ever
get skips with stock 2.4 or with O11int. 

Also, I noticed today that while the system was under moderate load
(~100 procmail/sendmail pairs filtering mail through spamassassin +
Firebird + xmms), starting an app like emacs took ages. I had to wait
and wait and finally only when I tried to open a second instance did
the first one come up. That did not happen before..

	- Apurva