[ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

This version continues the major gutting of the SPA based schedulers to
reduce overhead.  The inclusion of the mechanisms for gathering and
displaying accrued scheduling statistics have been remove as they are 
not an integral part of the scheduler and were mainly there to help with 
tuning.  Sorry Jake, if you still need these for your genetic algorithm 
work I can provide a patch to add them to all schedulers?

Additionally, the mechanism for auto detection and preferential
treatment of media streamers in the spa_ws scheduler has been removed. 
The reason for this is that my testing shows that the performance of 
media streamers on spa_ws is adequate without it.

Modifications have been made to spa_ws to (hopefully) address the issues 
raised by Paolo Ornati recently and a new entitlement based 
interpretation of "nice" scheduler, spa_ebs, which is a cut down version 
of the Zaphod schedulers "eb" mode has been added as this mode of Zaphod 
performed will for Paolo's problem when he tried it at my request. 
Paolo, could you please give these a test drive on your problem?

A patch for 2.6.16-rc1 is available at:

<http://prdownloads.sourceforge.net/cpuse/plugsched-6.2-for-2.6.16-rc1.patch?download>

and a patch for 2.6.16-rc1-mm1 is available at:

<http://prdownloads.sourceforge.net/cpuse/plugsched-6.2-for-2.6.16-rc1-mm1.patch?download>

Very Brief Documentation:

You can select a default scheduler at kernel build time.  If you wish to
boot with a scheduler other than the default it can be selected at boot
time by adding:

cpusched=<scheduler>

to the boot command line where <scheduler> is one of: ingosched,
nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs or zaphod. 
  If you don't change the default when you build the kernel the default 
scheduler will be ingosched (which is the normal scheduler).

The scheduler in force on a running system can be determined by the
contents of:

/proc/scheduler

Control parameters for the scheduler can be read/set via files in:

/sys/cpusched/<scheduler>/

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Peter Williams wrote:
> This version continues the major gutting of the SPA based schedulers to
> reduce overhead.  The inclusion of the mechanisms for gathering and
> displaying accrued scheduling statistics have been remove as they are 
> not an integral part of the scheduler and were mainly there to help with 
> tuning.  Sorry Jake, if you still need these for your genetic algorithm 
> work I can provide a patch to add them to all schedulers?
> 
> Additionally, the mechanism for auto detection and preferential
> treatment of media streamers in the spa_ws scheduler has been removed. 
> The reason for this is that my testing shows that the performance of 
> media streamers on spa_ws is adequate without it.
> 
> Modifications have been made to spa_ws to (hopefully) address the issues 
> raised by Paolo Ornati recently and a new entitlement based 
> interpretation of "nice" scheduler, spa_ebs, which is a cut down version 
> of the Zaphod schedulers "eb" mode has been added as this mode of Zaphod 
> performed will for Paolo's problem when he tried it at my request. 
> Paolo, could you please give these a test drive on your problem?
> 
> A patch for 2.6.16-rc1 is available at:
> 
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.2-for-2.6.16-rc1.patch?download> 
> 
> 
> and a patch for 2.6.16-rc1-mm1 is available at:
> 
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.2-for-2.6.16-rc1-mm1.patch?download> 
> 

Applies cleanly to 2.6.16-rc1-mm2.

> 
> Very Brief Documentation:
> 
> You can select a default scheduler at kernel build time.  If you wish to
> boot with a scheduler other than the default it can be selected at boot
> time by adding:
> 
> cpusched=<scheduler>
> 
> to the boot command line where <scheduler> is one of: ingosched,
> nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs or zaphod. 
>  If you don't change the default when you build the kernel the default 
> scheduler will be ingosched (which is the normal scheduler).
> 
> The scheduler in force on a running system can be determined by the
> contents of:
> 
> /proc/scheduler
> 
> Control parameters for the scheduler can be read/set via files in:
> 
> /sys/cpusched/<scheduler>/
> 
> Peter


-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Fri, 20 Jan 2006 08:45:43 +1100
Peter Williams <pwil3058@bigpond.net.au> wrote:

> Modifications have been made to spa_ws to (hopefully) address the issues 
> raised by Paolo Ornati recently and a new entitlement based 
> interpretation of "nice" scheduler, spa_ebs, which is a cut down version 
> of the Zaphod schedulers "eb" mode has been added as this mode of Zaphod 
> performed will for Paolo's problem when he tried it at my request. 
> Paolo, could you please give these a test drive on your problem?

---- spa_ws: the problem is still here

(sched_fooler)
./a.out 3000 & ./a.out 4307 &

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5573 paolo     34   0  2396  292  228 R 59.0  0.1   0:24.51 a.out
 5572 paolo     34   0  2392  288  228 R 40.7  0.1   0:16.94 a.out
 5580 paolo     35   0  4948 1468  372 R  0.3  0.3   0:00.04 dd

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5573 paolo     34   0  2396  292  228 R 59.3  0.1   0:59.65 a.out
 5572 paolo     33   0  2392  288  228 R 40.3  0.1   0:41.32 a.out
 5440 paolo     28   0 86652  21m  15m S  0.3  4.4   0:03.34 konsole
 5580 paolo     37   0  4948 1468  372 R  0.3  0.3   0:00.10 dd


(real life - transcode)
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5585 paolo     33   0  115m  18m 2432 S 90.0  3.7   0:38.04 transcode
 5599 paolo     37   0 50996 4472 1872 R  9.1  0.9   0:04.03 tcdecode
 5610 paolo     37   0  4948 1468  372 R  0.6  0.3   0:00.19 dd


DD test takes ages in both cases.

What exactly have you done to spa_ws?


---- spa_ebs: great! (as expected)

(sched_fooler)
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5418 paolo     34   0  2392  288  228 R 51.4  0.1   1:06.47 a.out
 5419 paolo     34   0  2392  288  228 R 43.7  0.1   0:54.60 a.out
 5448 paolo     11   0  4952 1468  372 D  3.0  0.3   0:00.12 dd

(transcode)
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5456 paolo     34   0  115m  18m 2432 R 51.9  3.7   0:23.34 transcode
 5470 paolo     12   0 51000 4472 1872 S  5.7  0.9   0:02.38 tcdecode
 5480 paolo     11   0  4948 1468  372 D  3.5  0.3   0:00.33 dd

Very good DD test performance in both cases.


-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Paolo Ornati wrote:
> On Fri, 20 Jan 2006 08:45:43 +1100
> Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>Modifications have been made to spa_ws to (hopefully) address the issues 
>>raised by Paolo Ornati recently and a new entitlement based 
>>interpretation of "nice" scheduler, spa_ebs, which is a cut down version 
>>of the Zaphod schedulers "eb" mode has been added as this mode of Zaphod 
>>performed will for Paolo's problem when he tried it at my request. 
>>Paolo, could you please give these a test drive on your problem?
> 
> 
> ---- spa_ws: the problem is still here
> 
> (sched_fooler)
> ./a.out 3000 & ./a.out 4307 &
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5573 paolo     34   0  2396  292  228 R 59.0  0.1   0:24.51 a.out
>  5572 paolo     34   0  2392  288  228 R 40.7  0.1   0:16.94 a.out
>  5580 paolo     35   0  4948 1468  372 R  0.3  0.3   0:00.04 dd
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5573 paolo     34   0  2396  292  228 R 59.3  0.1   0:59.65 a.out
>  5572 paolo     33   0  2392  288  228 R 40.3  0.1   0:41.32 a.out
>  5440 paolo     28   0 86652  21m  15m S  0.3  4.4   0:03.34 konsole
>  5580 paolo     37   0  4948 1468  372 R  0.3  0.3   0:00.10 dd
> 
> 
> (real life - transcode)
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5585 paolo     33   0  115m  18m 2432 S 90.0  3.7   0:38.04 transcode
>  5599 paolo     37   0 50996 4472 1872 R  9.1  0.9   0:04.03 tcdecode
>  5610 paolo     37   0  4948 1468  372 R  0.6  0.3   0:00.19 dd
> 
> 
> DD test takes ages in both cases.
> 
> What exactly have you done to spa_ws?

I added a "nice aware" version of the throughput bonuses from spa_svr 
and renamed them fairness bonus.  They don't appear to be working :-(

34 is the priority value that ordinary tasks should end up with i.e. if 
they don't look like interactive tasks or CPU hogs.  If they look like 
interactive tasks they should get a lower one via the interactive bonus 
mechanism and if they look like CPU hogs they should get a higher one 
via the same mechanism.  In addition to this tasks will get bonuses if 
they seem to be being treated unfairly i.e. spending too much time on 
run queues waiting for CPU access.

Looking at your numbers the transcode task has the priority that I'd 
expect it to have but tcdecode and dd seem to have had their priorities 
adjusted in the wrong direction.   It's almost like they'd been 
(incorrectly, obviously) identified as CPU hogs :-(.  I'll look into this.

> 
> 
> ---- spa_ebs: great! (as expected)
> 
> (sched_fooler)
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5418 paolo     34   0  2392  288  228 R 51.4  0.1   1:06.47 a.out
>  5419 paolo     34   0  2392  288  228 R 43.7  0.1   0:54.60 a.out
>  5448 paolo     11   0  4952 1468  372 D  3.0  0.3   0:00.12 dd
> 
> (transcode)
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5456 paolo     34   0  115m  18m 2432 R 51.9  3.7   0:23.34 transcode
>  5470 paolo     12   0 51000 4472 1872 S  5.7  0.9   0:02.38 tcdecode
>  5480 paolo     11   0  4948 1468  372 D  3.5  0.3   0:00.33 dd
> 
> Very good DD test performance in both cases.

Good.  How do you find the interactive responsiveness with this one?

Thanks for testing
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Peter Williams wrote:
> Paolo Ornati wrote:
> 
>> On Fri, 20 Jan 2006 08:45:43 +1100
>> Peter Williams <pwil3058@bigpond.net.au> wrote:
>>
>>
>>> Modifications have been made to spa_ws to (hopefully) address the 
>>> issues raised by Paolo Ornati recently and a new entitlement based 
>>> interpretation of "nice" scheduler, spa_ebs, which is a cut down 
>>> version of the Zaphod schedulers "eb" mode has been added as this 
>>> mode of Zaphod performed will for Paolo's problem when he tried it at 
>>> my request. Paolo, could you please give these a test drive on your 
>>> problem?
>>
>>
>>
>> ---- spa_ws: the problem is still here
>>
>> (sched_fooler)
>> ./a.out 3000 & ./a.out 4307 &
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5573 paolo     34   0  2396  292  228 R 59.0  0.1   0:24.51 a.out
>>  5572 paolo     34   0  2392  288  228 R 40.7  0.1   0:16.94 a.out
>>  5580 paolo     35   0  4948 1468  372 R  0.3  0.3   0:00.04 dd
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5573 paolo     34   0  2396  292  228 R 59.3  0.1   0:59.65 a.out
>>  5572 paolo     33   0  2392  288  228 R 40.3  0.1   0:41.32 a.out
>>  5440 paolo     28   0 86652  21m  15m S  0.3  4.4   0:03.34 konsole
>>  5580 paolo     37   0  4948 1468  372 R  0.3  0.3   0:00.10 dd
>>
>>
>> (real life - transcode)
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5585 paolo     33   0  115m  18m 2432 S 90.0  3.7   0:38.04 transcode
>>  5599 paolo     37   0 50996 4472 1872 R  9.1  0.9   0:04.03 tcdecode
>>  5610 paolo     37   0  4948 1468  372 R  0.6  0.3   0:00.19 dd
>>
>>
>> DD test takes ages in both cases.
>>
>> What exactly have you done to spa_ws?
> 
> 
> I added a "nice aware" version of the throughput bonuses from spa_svr 
> and renamed them fairness bonus.  They don't appear to be working :-(
> 
> 34 is the priority value that ordinary tasks should end up with i.e. if 
> they don't look like interactive tasks or CPU hogs.  If they look like 
> interactive tasks they should get a lower one via the interactive bonus 
> mechanism and if they look like CPU hogs they should get a higher one 
> via the same mechanism.  In addition to this tasks will get bonuses if 
> they seem to be being treated unfairly i.e. spending too much time on 
> run queues waiting for CPU access.
> 
> Looking at your numbers the transcode task has the priority that I'd 
> expect it to have but tcdecode and dd seem to have had their priorities 
> adjusted in the wrong direction.   It's almost like they'd been 
> (incorrectly, obviously) identified as CPU hogs :-(.  I'll look into this.

I forgot that I'd also made changes to the "CPU hog" component of the 
interactive response as the one I had was useless on heavily loaded 
systems.  It appears that I made a mistake (I used interactive 
sleepiness instead of ordinary sleepiness for detecting CPU hogs) during 
these changes which means that tasks that do no interactive sleeping 
(such as your dd) get classified as CPU hogs.  The transcode task 
escapes this because, although its sleeps aren't really interactive, 
they're classified as such.  More widespread us of TASK_NONINTERACTIVE 
would fix this but would need to be done carefully as it would risk 
breaking the normal scheduler.

However, in spite of the above, the fairness mechanism should have been 
able to generate enough bonus points to get dd's priority back to less 
than 34.  I'm still investigating why this didn't happen.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

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

Peter Williams wrote:
> Peter Williams wrote:
> 
>> Paolo Ornati wrote:
>>
>>> On Fri, 20 Jan 2006 08:45:43 +1100
>>> Peter Williams <pwil3058@bigpond.net.au> wrote:
>>>
>>>
>>>> Modifications have been made to spa_ws to (hopefully) address the 
>>>> issues raised by Paolo Ornati recently and a new entitlement based 
>>>> interpretation of "nice" scheduler, spa_ebs, which is a cut down 
>>>> version of the Zaphod schedulers "eb" mode has been added as this 
>>>> mode of Zaphod performed will for Paolo's problem when he tried it 
>>>> at my request. Paolo, could you please give these a test drive on 
>>>> your problem?
>>>
>>>
>>>
>>>
>>> ---- spa_ws: the problem is still here
>>>
>>> (sched_fooler)
>>> ./a.out 3000 & ./a.out 4307 &
>>>
>>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  5573 paolo     34   0  2396  292  228 R 59.0  0.1   0:24.51 a.out
>>>  5572 paolo     34   0  2392  288  228 R 40.7  0.1   0:16.94 a.out
>>>  5580 paolo     35   0  4948 1468  372 R  0.3  0.3   0:00.04 dd
>>>
>>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  5573 paolo     34   0  2396  292  228 R 59.3  0.1   0:59.65 a.out
>>>  5572 paolo     33   0  2392  288  228 R 40.3  0.1   0:41.32 a.out
>>>  5440 paolo     28   0 86652  21m  15m S  0.3  4.4   0:03.34 konsole
>>>  5580 paolo     37   0  4948 1468  372 R  0.3  0.3   0:00.10 dd
>>>
>>>
>>> (real life - transcode)
>>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  5585 paolo     33   0  115m  18m 2432 S 90.0  3.7   0:38.04 transcode
>>>  5599 paolo     37   0 50996 4472 1872 R  9.1  0.9   0:04.03 tcdecode
>>>  5610 paolo     37   0  4948 1468  372 R  0.6  0.3   0:00.19 dd
>>>
>>>
>>> DD test takes ages in both cases.
>>>
>>> What exactly have you done to spa_ws?
>>
>>
>>
>> I added a "nice aware" version of the throughput bonuses from spa_svr 
>> and renamed them fairness bonus.  They don't appear to be working :-(
>>
>> 34 is the priority value that ordinary tasks should end up with i.e. 
>> if they don't look like interactive tasks or CPU hogs.  If they look 
>> like interactive tasks they should get a lower one via the interactive 
>> bonus mechanism and if they look like CPU hogs they should get a 
>> higher one via the same mechanism.  In addition to this tasks will get 
>> bonuses if they seem to be being treated unfairly i.e. spending too 
>> much time on run queues waiting for CPU access.
>>
>> Looking at your numbers the transcode task has the priority that I'd 
>> expect it to have but tcdecode and dd seem to have had their 
>> priorities adjusted in the wrong direction.   It's almost like they'd 
>> been (incorrectly, obviously) identified as CPU hogs :-(.  I'll look 
>> into this.
> 
> 
> I forgot that I'd also made changes to the "CPU hog" component of the 
> interactive response as the one I had was useless on heavily loaded 
> systems.  It appears that I made a mistake (I used interactive 
> sleepiness instead of ordinary sleepiness for detecting CPU hogs) during 
> these changes which means that tasks that do no interactive sleeping 
> (such as your dd) get classified as CPU hogs.  The transcode task 
> escapes this because, although its sleeps aren't really interactive, 
> they're classified as such.  More widespread us of TASK_NONINTERACTIVE 
> would fix this but would need to be done carefully as it would risk 
> breaking the normal scheduler.
> 
> However, in spite of the above, the fairness mechanism should have been 
> able to generate enough bonus points to get dd's priority back to less 
> than 34.  I'm still investigating why this didn't happen.

Problem solved.  It was a scaling issue during the calculation of 
expected delay.  The attached patch should fix both the CPU hog problem 
and the fairness problem.  Could you give it a try?

Thanks,
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

[-- Attachment #2: fix-spa_ws-scheduler --]
[-- Type: text/plain, Size: 4729 bytes --]

Index: MM-2.6.16/kernel/sched_spa_ws.c
===================================================================
--- MM-2.6.16.orig/kernel/sched_spa_ws.c	2006-01-21 16:42:45.000000000 +1100
+++ MM-2.6.16/kernel/sched_spa_ws.c	2006-01-23 11:42:32.000000000 +1100
@@ -44,7 +44,8 @@ static unsigned int initial_ia_bonus = D
 #define LSHARES_AVG_OFFSET 7
 #define LSHARES_AVG_ALPHA ((1 << LSHARES_AVG_OFFSET) - 2)
 #define LSHARES_AVG_INCR(a) ((a) << 1)
-#define LSHARES_AVG_ONE (1UL << LSHARES_AVG_OFFSET)
+#define LSHARES_AVG_REAL(s) ((s) << LSHARES_AVG_OFFSET)
+#define LSHARES_AVG_ONE LSAHRES_AVG_REAL(1UL)
 #define LSHARES_AVG_MUL(a, b) (((a) * (b)) >> LSHARES_AVG_OFFSET)
 
 static unsigned int max_fairness_bonus = DEF_MAX_FAIRNESS_BONUS;
@@ -121,32 +122,9 @@ static inline void zero_interactive_bonu
 	p->sdu.spa.interactive_bonus = 0;
 }
 
-static inline int current_fairness_bonus(const struct task_struct *p)
-{
-	return p->sdu.spa.auxilary_bonus >> FAIRNESS_BONUS_OFFSET;
-}
-
-static inline int current_fairness_bonus_rnd(const struct task_struct *p)
-{
-	return (p->sdu.spa.auxilary_bonus + (1UL << (FAIRNESS_BONUS_OFFSET - 1)))
-		>> FAIRNESS_BONUS_OFFSET;
-}
-
-static inline void decr_fairness_bonus(struct task_struct *p)
-{
-	p->sdu.spa.auxilary_bonus *= ((1UL << FAIRNESS_BONUS_OFFSET) - 2);
-	p->sdu.spa.auxilary_bonus >>= FAIRNESS_BONUS_OFFSET;
-}
-
-static inline void incr_fairness_bonus(struct task_struct *p)
-{
-	decr_fairness_bonus(p);
-	p->sdu.spa.auxilary_bonus += (max_fairness_bonus << 1);
-}
-
 static inline int bonuses(const struct task_struct *p)
 {
-	return current_ia_bonus_rnd(p) + current_fairness_bonus_rnd(p);
+	return current_ia_bonus_rnd(p) + p->sdu.spa.auxilary_bonus;
 }
 
 static int spa_ws_effective_prio(const struct task_struct *p)
@@ -211,43 +189,36 @@ static inline unsigned int map_ratio(uns
 
 static void spa_ws_reassess_fairness_bonus(struct task_struct *p)
 {
-	unsigned long long expected_delay;
+	unsigned long long expected_delay, adjusted_delay;
 	unsigned long long avg_lshares;
+	unsigned long pshares = LSHARES_AVG_REAL(p->sdu.spa.eb_shares);
 
-#if 0
 	p->sdu.spa.auxilary_bonus = 0;
 	if (max_fairness_bonus == 0)
 		return;
-#endif
 
 	avg_lshares = per_cpu(rq_avg_lshares, task_cpu(p));
-	if (avg_lshares <= p->sdu.spa.eb_shares)
+	if (avg_lshares <= pshares)
 		expected_delay = 0;
 	else {
 		expected_delay = LSHARES_AVG_MUL(p->sdu.spa.avg_cpu_per_cycle,
-				      (avg_lshares - p->sdu.spa.eb_shares));
-		(void)do_div(expected_delay, p->sdu.spa.eb_shares);
+				      (avg_lshares - pshares));
+		(void)do_div(expected_delay, pshares);
 	}
-#if 1
-	if (p->sdu.spa.avg_delay_per_cycle > expected_delay)
-		incr_fairness_bonus(p);
-	else
-		decr_fairness_bonus(p);
-#else
+
 	/*
 	 * No delay means no bonus, but
 	 * NB this test also avoids a possible divide by zero error if
 	 * cpu is also zero and negative bonuses
 	 */
-	lhs = p->sdu.spa.avg_delay_per_cycle;
-	if (lhs <= rhs)
+	if (p->sdu.spa.avg_delay_per_cycle <= expected_delay)
 		return;
 
-	lhs  -= rhs;
+	adjusted_delay = p->sdu.spa.avg_delay_per_cycle - expected_delay;
 	p->sdu.spa.auxilary_bonus =
-		map_ratio(lhs, lhs + p->sdu.spa.avg_cpu_per_cycle,
+		map_ratio(adjusted_delay,
+			  adjusted_delay + p->sdu.spa.avg_cpu_per_cycle,
 			  max_fairness_bonus);
-#endif
 }
 
 static inline int spa_ws_eligible(struct task_struct *p)
@@ -255,6 +226,15 @@ static inline int spa_ws_eligible(struct
 	return p->sdu.spa.avg_sleep_per_cycle < WS_BIG_SLEEP;
 }
 
+static inline int spa_sleepiness_exceeds_ppt(const struct task_struct *p,
+					    unsigned int ppt)
+{
+	return RATIO_EXCEEDS_PPT(p->sdu.spa.avg_sleep_per_cycle,
+				 p->sdu.spa.avg_sleep_per_cycle +
+				 p->sdu.spa.avg_cpu_per_cycle,
+				 ppt);
+}
+
 static void spa_ws_reassess_at_activation(struct task_struct *p)
 {
 	spa_ws_reassess_fairness_bonus(p);
@@ -264,7 +244,7 @@ static void spa_ws_reassess_at_activatio
 		else
 			partial_incr_interactive_bonus(p);
 	}
-	else if (!spa_ia_sleepiness_exceeds_ppt(p, iab_decr_threshold))
+	else if (!spa_sleepiness_exceeds_ppt(p, iab_decr_threshold))
 		decr_interactive_bonus(p);
 	else if (!spa_ia_sleepiness_exceeds_ppt(p, (iab_decr_threshold + iab_incr_threshold) / 2))
 		partial_decr_interactive_bonus(p);
@@ -284,7 +264,7 @@ static void spa_ws_reassess_at_end_of_ts
 	/* Don't punish tasks that have done a lot of sleeping for the
 	 * occasional run of short sleeps unless they become a cpu hog.
 	 */
-	if (!spa_ia_sleepiness_exceeds_ppt(p, iab_decr_threshold))
+	if (!spa_sleepiness_exceeds_ppt(p, iab_decr_threshold))
 		decr_interactive_bonus(p);
 	else if (!spa_ia_sleepiness_exceeds_ppt(p, (iab_decr_threshold + iab_incr_threshold) / 2))
 		partial_decr_interactive_bonus(p);

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Mon, 23 Jan 2006 11:49:33 +1100
Peter Williams <pwil3058@bigpond.net.au> wrote:

> > 
> > However, in spite of the above, the fairness mechanism should have been 
> > able to generate enough bonus points to get dd's priority back to less 
> > than 34.  I'm still investigating why this didn't happen.
> 
> Problem solved.  It was a scaling issue during the calculation of 
> expected delay.  The attached patch should fix both the CPU hog problem 
> and the fairness problem.  Could you give it a try?
> 

Mmmm... it doesn't work:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5516 paolo     34   0  115m  18m 2432 S 87.5  3.7   0:23.72 transcode
 5530 paolo     34   0 51000 4472 1872 S  8.0  0.9   0:02.29 tcdecode
 5523 paolo     34   0 19840 1088  880 R  2.0  0.2   0:00.21 tcdemux
 5522 paolo     34   0 22156 1204  972 R  0.7  0.2   0:00.02 tccat
 5539 paolo     34   0  4952 1468  372 D  0.7  0.3   0:00.04 dd
 5350 root      28   0  167m  16m 3228 S  0.3  3.4   0:03.64 X

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5456 paolo     34   0  115m  18m 2432 D 63.9  3.7   0:48.21 transcode
 5470 paolo     37   0 50996 4472 1872 R  6.2  0.9   0:05.20 tcdecode
 5493 paolo     34   0  4952 1472  372 R  1.5  0.3   0:00.22 dd
 5441 paolo     28   0 86656  21m  15m S  0.2  4.4   0:00.77 konsole
 5468 paolo     34   0 19840 1088  880 S  0.2  0.2   0:00.23 tcdemux

-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Paolo Ornati wrote:
> On Mon, 23 Jan 2006 11:49:33 +1100
> Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>>However, in spite of the above, the fairness mechanism should have been 
>>>able to generate enough bonus points to get dd's priority back to less 
>>>than 34.  I'm still investigating why this didn't happen.
>>
>>Problem solved.  It was a scaling issue during the calculation of 
>>expected delay.  The attached patch should fix both the CPU hog problem 
>>and the fairness problem.  Could you give it a try?
>>
> 
> 
> Mmmm... it doesn't work:
> 
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5516 paolo     34   0  115m  18m 2432 S 87.5  3.7   0:23.72 transcode
>  5530 paolo     34   0 51000 4472 1872 S  8.0  0.9   0:02.29 tcdecode
>  5523 paolo     34   0 19840 1088  880 R  2.0  0.2   0:00.21 tcdemux
>  5522 paolo     34   0 22156 1204  972 R  0.7  0.2   0:00.02 tccat
>  5539 paolo     34   0  4952 1468  372 D  0.7  0.3   0:00.04 dd
>  5350 root      28   0  167m  16m 3228 S  0.3  3.4   0:03.64 X
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5456 paolo     34   0  115m  18m 2432 D 63.9  3.7   0:48.21 transcode
>  5470 paolo     37   0 50996 4472 1872 R  6.2  0.9   0:05.20 tcdecode
>  5493 paolo     34   0  4952 1472  372 R  1.5  0.3   0:00.22 dd
>  5441 paolo     28   0 86656  21m  15m S  0.2  4.4   0:00.77 konsole
>  5468 paolo     34   0 19840 1088  880 S  0.2  0.2   0:00.23 tcdemux
> 

Bummer.  At least it didn't classify dd as CPU intensive but the 
fairness bonus doesn't seem to have kicked in.  It's currently awarded 
as a "one of" bonus each time a delay is too long and I think that it 
needs to be a bit more persistent over time.

Thanks for testing
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

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

Paolo Ornati wrote:
> On Mon, 23 Jan 2006 11:49:33 +1100
> Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>>However, in spite of the above, the fairness mechanism should have been 
>>>able to generate enough bonus points to get dd's priority back to less 
>>>than 34.  I'm still investigating why this didn't happen.
>>
>>Problem solved.  It was a scaling issue during the calculation of 
>>expected delay.  The attached patch should fix both the CPU hog problem 
>>and the fairness problem.  Could you give it a try?
>>
> 
> 
> Mmmm... it doesn't work:
> 
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5516 paolo     34   0  115m  18m 2432 S 87.5  3.7   0:23.72 transcode
>  5530 paolo     34   0 51000 4472 1872 S  8.0  0.9   0:02.29 tcdecode
>  5523 paolo     34   0 19840 1088  880 R  2.0  0.2   0:00.21 tcdemux
>  5522 paolo     34   0 22156 1204  972 R  0.7  0.2   0:00.02 tccat
>  5539 paolo     34   0  4952 1468  372 D  0.7  0.3   0:00.04 dd
>  5350 root      28   0  167m  16m 3228 S  0.3  3.4   0:03.64 X
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5456 paolo     34   0  115m  18m 2432 D 63.9  3.7   0:48.21 transcode
>  5470 paolo     37   0 50996 4472 1872 R  6.2  0.9   0:05.20 tcdecode
>  5493 paolo     34   0  4952 1472  372 R  1.5  0.3   0:00.22 dd
>  5441 paolo     28   0 86656  21m  15m S  0.2  4.4   0:00.77 konsole
>  5468 paolo     34   0 19840 1088  880 S  0.2  0.2   0:00.23 tcdemux
> 

I know that I've said this before but I've found the problem. 
Embarrassingly, it was a basic book keeping error (recently introduced 
and equivalent to getting nr_running wrong for each CPU) in the 
gathering of the statistics that I use. :-(

The attached patch (applied on top of the PlugSched patch) should fix 
things.  Could you test it please?

Thanks
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

[-- Attachment #2: fix-spa_ws-scheduler-v2 --]
[-- Type: text/plain, Size: 7444 bytes --]

Index: MM-2.6.16/kernel/sched_spa_ws.c
===================================================================
--- MM-2.6.16.orig/kernel/sched_spa_ws.c	2006-01-21 16:42:45.000000000 +1100
+++ MM-2.6.16/kernel/sched_spa_ws.c	2006-01-26 11:44:14.000000000 +1100
@@ -44,7 +44,8 @@ static unsigned int initial_ia_bonus = D
 #define LSHARES_AVG_OFFSET 7
 #define LSHARES_AVG_ALPHA ((1 << LSHARES_AVG_OFFSET) - 2)
 #define LSHARES_AVG_INCR(a) ((a) << 1)
-#define LSHARES_AVG_ONE (1UL << LSHARES_AVG_OFFSET)
+#define LSHARES_AVG_REAL(s) ((s) << LSHARES_AVG_OFFSET)
+#define LSHARES_AVG_ONE LSAHRES_AVG_REAL(1UL)
 #define LSHARES_AVG_MUL(a, b) (((a) * (b)) >> LSHARES_AVG_OFFSET)
 
 static unsigned int max_fairness_bonus = DEF_MAX_FAIRNESS_BONUS;
@@ -121,32 +122,9 @@ static inline void zero_interactive_bonu
 	p->sdu.spa.interactive_bonus = 0;
 }
 
-static inline int current_fairness_bonus(const struct task_struct *p)
-{
-	return p->sdu.spa.auxilary_bonus >> FAIRNESS_BONUS_OFFSET;
-}
-
-static inline int current_fairness_bonus_rnd(const struct task_struct *p)
-{
-	return (p->sdu.spa.auxilary_bonus + (1UL << (FAIRNESS_BONUS_OFFSET - 1)))
-		>> FAIRNESS_BONUS_OFFSET;
-}
-
-static inline void decr_fairness_bonus(struct task_struct *p)
-{
-	p->sdu.spa.auxilary_bonus *= ((1UL << FAIRNESS_BONUS_OFFSET) - 2);
-	p->sdu.spa.auxilary_bonus >>= FAIRNESS_BONUS_OFFSET;
-}
-
-static inline void incr_fairness_bonus(struct task_struct *p)
-{
-	decr_fairness_bonus(p);
-	p->sdu.spa.auxilary_bonus += (max_fairness_bonus << 1);
-}
-
 static inline int bonuses(const struct task_struct *p)
 {
-	return current_ia_bonus_rnd(p) + current_fairness_bonus_rnd(p);
+	return current_ia_bonus_rnd(p) + p->sdu.spa.auxilary_bonus;
 }
 
 static int spa_ws_effective_prio(const struct task_struct *p)
@@ -211,43 +189,37 @@ static inline unsigned int map_ratio(uns
 
 static void spa_ws_reassess_fairness_bonus(struct task_struct *p)
 {
-	unsigned long long expected_delay;
+	unsigned long long expected_delay, adjusted_delay;
 	unsigned long long avg_lshares;
+	unsigned long pshares;
 
-#if 0
 	p->sdu.spa.auxilary_bonus = 0;
 	if (max_fairness_bonus == 0)
 		return;
-#endif
 
+	pshares = LSHARES_AVG_REAL(p->sdu.spa.eb_shares);
 	avg_lshares = per_cpu(rq_avg_lshares, task_cpu(p));
-	if (avg_lshares <= p->sdu.spa.eb_shares)
+	if (avg_lshares <= pshares)
 		expected_delay = 0;
 	else {
-		expected_delay = LSHARES_AVG_MUL(p->sdu.spa.avg_cpu_per_cycle,
-				      (avg_lshares - p->sdu.spa.eb_shares));
-		(void)do_div(expected_delay, p->sdu.spa.eb_shares);
+		expected_delay = p->sdu.spa.avg_cpu_per_cycle *
+			(avg_lshares - pshares);
+		(void)do_div(expected_delay, pshares);
 	}
-#if 1
-	if (p->sdu.spa.avg_delay_per_cycle > expected_delay)
-		incr_fairness_bonus(p);
-	else
-		decr_fairness_bonus(p);
-#else
+
 	/*
 	 * No delay means no bonus, but
 	 * NB this test also avoids a possible divide by zero error if
 	 * cpu is also zero and negative bonuses
 	 */
-	lhs = p->sdu.spa.avg_delay_per_cycle;
-	if (lhs <= rhs)
+	if (p->sdu.spa.avg_delay_per_cycle <= expected_delay)
 		return;
 
-	lhs  -= rhs;
+	adjusted_delay = p->sdu.spa.avg_delay_per_cycle - expected_delay;
 	p->sdu.spa.auxilary_bonus =
-		map_ratio(lhs, lhs + p->sdu.spa.avg_cpu_per_cycle,
+		map_ratio(adjusted_delay,
+			  adjusted_delay + p->sdu.spa.avg_cpu_per_cycle,
 			  max_fairness_bonus);
-#endif
 }
 
 static inline int spa_ws_eligible(struct task_struct *p)
@@ -255,6 +227,15 @@ static inline int spa_ws_eligible(struct
 	return p->sdu.spa.avg_sleep_per_cycle < WS_BIG_SLEEP;
 }
 
+static inline int spa_sleepiness_exceeds_ppt(const struct task_struct *p,
+					    unsigned int ppt)
+{
+	return RATIO_EXCEEDS_PPT(p->sdu.spa.avg_sleep_per_cycle,
+				 p->sdu.spa.avg_sleep_per_cycle +
+				 p->sdu.spa.avg_cpu_per_cycle,
+				 ppt);
+}
+
 static void spa_ws_reassess_at_activation(struct task_struct *p)
 {
 	spa_ws_reassess_fairness_bonus(p);
@@ -264,7 +245,7 @@ static void spa_ws_reassess_at_activatio
 		else
 			partial_incr_interactive_bonus(p);
 	}
-	else if (!spa_ia_sleepiness_exceeds_ppt(p, iab_decr_threshold))
+	else if (!spa_sleepiness_exceeds_ppt(p, iab_decr_threshold))
 		decr_interactive_bonus(p);
 	else if (!spa_ia_sleepiness_exceeds_ppt(p, (iab_decr_threshold + iab_incr_threshold) / 2))
 		partial_decr_interactive_bonus(p);
@@ -284,7 +265,7 @@ static void spa_ws_reassess_at_end_of_ts
 	/* Don't punish tasks that have done a lot of sleeping for the
 	 * occasional run of short sleeps unless they become a cpu hog.
 	 */
-	if (!spa_ia_sleepiness_exceeds_ppt(p, iab_decr_threshold))
+	if (!spa_sleepiness_exceeds_ppt(p, iab_decr_threshold))
 		decr_interactive_bonus(p);
 	else if (!spa_ia_sleepiness_exceeds_ppt(p, (iab_decr_threshold + iab_incr_threshold) / 2))
 		partial_decr_interactive_bonus(p);
Index: MM-2.6.16/kernel/sched_spa.c
===================================================================
--- MM-2.6.16.orig/kernel/sched_spa.c	2006-01-21 16:41:32.000000000 +1100
+++ MM-2.6.16/kernel/sched_spa.c	2006-01-26 11:43:20.000000000 +1100
@@ -490,18 +490,29 @@ static inline int effective_prio(const t
 	return spa_sched_child->normal_effective_prio(p);
 }
 
+static inline void spa_inc_nr_running(task_t *p, runqueue_t *rq)
+{
+	inc_nr_running(p, rq);
+	check_restart_promotions(rq);
+	if (!rt_task(p))
+		rq->qu.spa.nr_active_eb_shares += p->sdu.spa.eb_shares;
+}
+
+static inline void spa_dec_nr_running(task_t *p, runqueue_t *rq)
+{
+	dec_nr_running(p, rq);
+	check_stop_promotions(rq);
+	if (!rt_task(p))
+		rq->qu.spa.nr_active_eb_shares -= p->sdu.spa.eb_shares;
+}
+
 /*
  * __activate_task - move a task to the runqueue.
  */
 static inline void __activate_task(task_t *p, runqueue_t *rq)
 {
-	struct spa_runqueue_queue *rqq = &rq->qu.spa;
-
-	enqueue_task(p, rqq);
-	inc_nr_running(p, rq);
-	check_restart_promotions(rq);
-	if (!rt_task(p))
-		rqq->nr_active_eb_shares += p->sdu.spa.eb_shares;
+	enqueue_task(p, &rq->qu.spa);
+	spa_inc_nr_running(p, rq);
 }
 
 static inline void do_nothing_to_task(task_t *p) {}
@@ -536,11 +547,8 @@ static inline void deactivate_task(struc
 {
 	struct spa_runqueue_queue *rqq = &rq->qu.spa;
 
-	dec_nr_running(p, rq);
+	spa_dec_nr_running(p, rq);
 	dequeue_task(p, rqq);
-	check_stop_promotions(rq);
-	if (!rt_task(p))
-		rqq->nr_active_eb_shares -= p->sdu.spa.eb_shares;
 }
 
 /*
@@ -648,7 +656,7 @@ void spa_wake_up_new_task(task_t * p, un
 			} else {
 				p->prio = current->prio;
 				list_add_tail(&p->run_list, &current->run_list);
-				inc_nr_running(p, rq);
+				spa_inc_nr_running(p, rq);
 				check_restart_promotions(rq);
 			}
 			set_need_resched();
@@ -678,13 +686,11 @@ static inline
 void pull_task(runqueue_t *src_rq, task_t *p, runqueue_t *this_rq, int this_cpu)
 {
 	dequeue_task(p, &src_rq->qu.spa);
-	dec_nr_running(p, src_rq);
-	check_stop_promotions(src_rq);
+	spa_dec_nr_running(p, src_rq);
 	set_task_cpu(p, this_cpu);
 	adjust_timestamp(p, this_rq, src_rq);
-	inc_nr_running(p, this_rq);
+	spa_inc_nr_running(p, this_rq);
 	enqueue_task(p, &this_rq->qu.spa);
-	check_restart_promotions(this_rq);
 	preempt_if_warranted(p, this_rq);
 }
 
@@ -1333,7 +1339,7 @@ void spa_set_select_idle_first(struct ru
 	__setscheduler(rq->idle, SCHED_FIFO, MAX_RT_PRIO - 1);
 	/* Add idle task to _front_ of it's priority queue */
 	enqueue_task_head(rq->idle, &rq->qu.spa);
-	inc_nr_running(rq->idle, rq);
+	spa_inc_nr_running(rq->idle, rq);
 }
 
 void spa_set_select_idle_last(struct runqueue *rq)

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Thu, 26 Jan 2006 12:09:53 +1100
Peter Williams <pwil3058@bigpond.net.au> wrote:

> I know that I've said this before but I've found the problem. 
> Embarrassingly, it was a basic book keeping error (recently introduced 
> and equivalent to getting nr_running wrong for each CPU) in the 
> gathering of the statistics that I use. :-(
> 
> The attached patch (applied on top of the PlugSched patch) should fix 
> things.  Could you test it please?

Ok, this one make a difference:

(transcode)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5774 paolo     34   0  116m  18m 2432 R 86.2  3.7   0:11.65 transcode
 5788 paolo     32   0 51000 4472 1872 S  7.5  0.9   0:01.13 tcdecode
 5797 paolo     29   0  4948 1468  372 D  3.2  0.3   0:00.30 dd
 5781 paolo     33   0 19844 1092  880 S  1.0  0.2   0:00.10 tcdemux
 5783 paolo     31   0 47964 2496 1956 S  0.7  0.5   0:00.08 tcdecode
 5786 paolo     34   0 19840 1088  880 R  0.5  0.2   0:00.06 tcdemux

(sched_fooler)

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5804 paolo     34   0  2396  292  228 R 35.7  0.1   0:12.84 a.out
 5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:11.49 a.out
 5805 paolo     34   0  2392  288  228 R 30.2  0.1   0:10.70 a.out
 5815 paolo     29   0  4948 1468  372 D  3.7  0.3   0:00.29 dd
 5458 paolo     28   0 86656  21m  15m S  0.2  4.4   0:02.18 konsole

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5804 paolo     34   0  2396  292  228 R 36.5  0.1   0:38.19 a.out
 5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:34.27 a.out
 5805 paolo     34   0  2392  288  228 R 29.2  0.1   0:32.39 a.out
 5829 paolo     34   0  4952 1472  372 R  3.2  0.3   0:00.35 dd

DD_TEST + sched_fooler: 512 MB --- ~20s instead of 16.6s

This is a clear improvement... however I wonder why DD priority
fluctuate going up even to 34 (the range is something like 29 <--->
34).

-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Paolo Ornati wrote:
> On Thu, 26 Jan 2006 12:09:53 +1100
> Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>I know that I've said this before but I've found the problem. 
>>Embarrassingly, it was a basic book keeping error (recently introduced 
>>and equivalent to getting nr_running wrong for each CPU) in the 
>>gathering of the statistics that I use. :-(
>>
>>The attached patch (applied on top of the PlugSched patch) should fix 
>>things.  Could you test it please?
> 
> 
> Ok, this one make a difference:
> 
> (transcode)
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5774 paolo     34   0  116m  18m 2432 R 86.2  3.7   0:11.65 transcode
>  5788 paolo     32   0 51000 4472 1872 S  7.5  0.9   0:01.13 tcdecode
>  5797 paolo     29   0  4948 1468  372 D  3.2  0.3   0:00.30 dd
>  5781 paolo     33   0 19844 1092  880 S  1.0  0.2   0:00.10 tcdemux
>  5783 paolo     31   0 47964 2496 1956 S  0.7  0.5   0:00.08 tcdecode
>  5786 paolo     34   0 19840 1088  880 R  0.5  0.2   0:00.06 tcdemux
> 
> (sched_fooler)
> 
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5804 paolo     34   0  2396  292  228 R 35.7  0.1   0:12.84 a.out
>  5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:11.49 a.out
>  5805 paolo     34   0  2392  288  228 R 30.2  0.1   0:10.70 a.out
>  5815 paolo     29   0  4948 1468  372 D  3.7  0.3   0:00.29 dd
>  5458 paolo     28   0 86656  21m  15m S  0.2  4.4   0:02.18 konsole
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  5804 paolo     34   0  2396  292  228 R 36.5  0.1   0:38.19 a.out
>  5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:34.27 a.out
>  5805 paolo     34   0  2392  288  228 R 29.2  0.1   0:32.39 a.out
>  5829 paolo     34   0  4952 1472  372 R  3.2  0.3   0:00.35 dd
> 
> DD_TEST + sched_fooler: 512 MB --- ~20s instead of 16.6s
> 
> This is a clear improvement... however I wonder why DD priority
> fluctuate going up even to 34 (the range is something like 29 <--->
> 34).
> 

It's because the "fairness" bonus is still being done as a one shot 
bonus when a task's delay time become unfairly large.  I mentioned this 
before as possibly needing to be changed to a more persistent model but 
after I discovered the accounting bug I deferred doing anything about it 
in the hope that fixing the bug would have been sufficient.

I'll now try a model whereby a task's fairness bonus is increased 
whenever it has unfair delays and decreased when it doesn't.  Hopefully, 
with the right rates of increase/decrease, this can result in a system 
where a task has a fairly persistent bonus which is sufficient to give 
it its fair share.  One reason that I've been avoiding this method is 
that it introduces double smoothing: once in the calculation of the 
average delay time and then again in the determination of the bonus; and 
I'm concerned this may make it slow to react to change.  Any way I'll 
give it a try and see what happens.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

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

Peter Williams wrote:
> Paolo Ornati wrote:
> 
>> On Thu, 26 Jan 2006 12:09:53 +1100
>> Peter Williams <pwil3058@bigpond.net.au> wrote:
>>
>>
>>> I know that I've said this before but I've found the problem. 
>>> Embarrassingly, it was a basic book keeping error (recently 
>>> introduced and equivalent to getting nr_running wrong for each CPU) 
>>> in the gathering of the statistics that I use. :-(
>>>
>>> The attached patch (applied on top of the PlugSched patch) should fix 
>>> things.  Could you test it please?
>>
>>
>>
>> Ok, this one make a difference:
>>
>> (transcode)
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5774 paolo     34   0  116m  18m 2432 R 86.2  3.7   0:11.65 transcode
>>  5788 paolo     32   0 51000 4472 1872 S  7.5  0.9   0:01.13 tcdecode
>>  5797 paolo     29   0  4948 1468  372 D  3.2  0.3   0:00.30 dd
>>  5781 paolo     33   0 19844 1092  880 S  1.0  0.2   0:00.10 tcdemux
>>  5783 paolo     31   0 47964 2496 1956 S  0.7  0.5   0:00.08 tcdecode
>>  5786 paolo     34   0 19840 1088  880 R  0.5  0.2   0:00.06 tcdemux
>>
>> (sched_fooler)
>>
>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5804 paolo     34   0  2396  292  228 R 35.7  0.1   0:12.84 a.out
>>  5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:11.49 a.out
>>  5805 paolo     34   0  2392  288  228 R 30.2  0.1   0:10.70 a.out
>>  5815 paolo     29   0  4948 1468  372 D  3.7  0.3   0:00.29 dd
>>  5458 paolo     28   0 86656  21m  15m S  0.2  4.4   0:02.18 konsole
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  5804 paolo     34   0  2396  292  228 R 36.5  0.1   0:38.19 a.out
>>  5803 paolo     34   0  2392  288  228 R 30.5  0.1   0:34.27 a.out
>>  5805 paolo     34   0  2392  288  228 R 29.2  0.1   0:32.39 a.out
>>  5829 paolo     34   0  4952 1472  372 R  3.2  0.3   0:00.35 dd
>>
>> DD_TEST + sched_fooler: 512 MB --- ~20s instead of 16.6s
>>
>> This is a clear improvement... however I wonder why DD priority
>> fluctuate going up even to 34 (the range is something like 29 <--->
>> 34).
>>
> 
> It's because the "fairness" bonus is still being done as a one shot 
> bonus when a task's delay time become unfairly large.  I mentioned this 
> before as possibly needing to be changed to a more persistent model but 
> after I discovered the accounting bug I deferred doing anything about it 
> in the hope that fixing the bug would have been sufficient.
> 
> I'll now try a model whereby a task's fairness bonus is increased 
> whenever it has unfair delays and decreased when it doesn't.  Hopefully, 
> with the right rates of increase/decrease, this can result in a system 
> where a task has a fairly persistent bonus which is sufficient to give 
> it its fair share.  One reason that I've been avoiding this method is 
> that it introduces double smoothing: once in the calculation of the 
> average delay time and then again in the determination of the bonus; and 
> I'm concerned this may make it slow to react to change.  Any way I'll 
> give it a try and see what happens.

Attached is a patch which makes the fairness bonuses more persistent.  I 
should be applied on top of the last patch that I sent.  Could you test 
it please?

Thanks
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

[-- Attachment #2: spa_ws-persistent-fairness --]
[-- Type: text/plain, Size: 3568 bytes --]

Index: MM-2.6.16/kernel/sched_spa_ws.c
===================================================================
--- MM-2.6.16.orig/kernel/sched_spa_ws.c	2006-01-26 12:21:50.000000000 +1100
+++ MM-2.6.16/kernel/sched_spa_ws.c	2006-01-29 10:00:21.000000000 +1100
@@ -45,12 +45,20 @@ static unsigned int initial_ia_bonus = D
 #define LSHARES_AVG_ALPHA ((1 << LSHARES_AVG_OFFSET) - 2)
 #define LSHARES_AVG_INCR(a) ((a) << 1)
 #define LSHARES_AVG_REAL(s) ((s) << LSHARES_AVG_OFFSET)
-#define LSHARES_AVG_ONE LSAHRES_AVG_REAL(1UL)
+#define LSHARES_AVG_ONE LSHARES_AVG_REAL(1UL)
 #define LSHARES_AVG_MUL(a, b) (((a) * (b)) >> LSHARES_AVG_OFFSET)
 
 static unsigned int max_fairness_bonus = DEF_MAX_FAIRNESS_BONUS;
 
-#define FAIRNESS_BONUS_OFFSET	8
+#define FAIRNESS_BONUS_OFFSET	5
+#define FAIRNESS_ALPHA		((1UL << FAIRNESS_BONUS_OFFSET) - 2)
+#define FAIRNESS_ALPHA_COMPL	2
+
+static inline int fairness_bonus(const struct task_struct *p)
+{
+	return (p->sdu.spa.auxilary_bonus * max_fairness_bonus) >>
+		FAIRNESS_BONUS_OFFSET;
+}
 
 static DEFINE_PER_CPU(unsigned long, rq_avg_lshares);
 
@@ -124,7 +132,7 @@ static inline void zero_interactive_bonu
 
 static inline int bonuses(const struct task_struct *p)
 {
-	return current_ia_bonus_rnd(p) + p->sdu.spa.auxilary_bonus;
+	return current_ia_bonus_rnd(p) + fairness_bonus(p);
 }
 
 static int spa_ws_effective_prio(const struct task_struct *p)
@@ -161,65 +169,22 @@ static void spa_ws_fork(struct task_stru
 	p->sdu.spa.interactive_bonus <<= IA_BONUS_OFFSET;
 }
 
-static inline unsigned int map_ratio(unsigned long long a,
-				     unsigned long long b,
-				     unsigned int range)
-{
-	a *= range;
-
-#if BITS_PER_LONG < 64
-	/*
-	 * Assume that there's no 64 bit divide available
-	 */
-	if (a < b)
-		return 0;
-	/*
-	 * Scale down until b less than 32 bits so that we can do
-	 * a divide using do_div()
-	 */
-	while (b > ULONG_MAX) { a >>= 1; b >>= 1; }
-
-	(void)do_div(a, (unsigned long)b);
-
-	return a;
-#else
-	return a / b;
-#endif
-}
-
 static void spa_ws_reassess_fairness_bonus(struct task_struct *p)
 {
-	unsigned long long expected_delay, adjusted_delay;
-	unsigned long long avg_lshares;
-	unsigned long pshares;
-
-	p->sdu.spa.auxilary_bonus = 0;
-	if (max_fairness_bonus == 0)
-		return;
+	unsigned long long expected_delay;
+	unsigned long long wanr; /* weighted average number running */
 
-	pshares = LSHARES_AVG_REAL(p->sdu.spa.eb_shares);
-	avg_lshares = per_cpu(rq_avg_lshares, task_cpu(p));
-	if (avg_lshares <= pshares)
+	wanr = per_cpu(rq_avg_lshares, task_cpu(p)) / p->sdu.spa.eb_shares;
+	if (wanr <= LSHARES_AVG_ONE)
 		expected_delay = 0;
-	else {
-		expected_delay = p->sdu.spa.avg_cpu_per_cycle *
-			(avg_lshares - pshares);
-		(void)do_div(expected_delay, pshares);
-	}
-
-	/*
-	 * No delay means no bonus, but
-	 * NB this test also avoids a possible divide by zero error if
-	 * cpu is also zero and negative bonuses
-	 */
-	if (p->sdu.spa.avg_delay_per_cycle <= expected_delay)
-		return;
-
-	adjusted_delay = p->sdu.spa.avg_delay_per_cycle - expected_delay;
-	p->sdu.spa.auxilary_bonus =
-		map_ratio(adjusted_delay,
-			  adjusted_delay + p->sdu.spa.avg_cpu_per_cycle,
-			  max_fairness_bonus);
+	else
+		expected_delay = LSHARES_AVG_MUL(p->sdu.spa.avg_cpu_per_cycle,
+						(wanr - LSHARES_AVG_ONE));
+
+	p->sdu.spa.auxilary_bonus *= FAIRNESS_ALPHA;
+	p->sdu.spa.auxilary_bonus >>= FAIRNESS_BONUS_OFFSET;
+	if (p->sdu.spa.avg_delay_per_cycle > expected_delay)
+		p->sdu.spa.auxilary_bonus += FAIRNESS_ALPHA_COMPL;
 }
 
 static inline int spa_ws_eligible(struct task_struct *p)

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Sun, 29 Jan 2006 10:44:17 +1100
Peter Williams <pwil3058@bigpond.net.au> wrote:

> Peter Williams wrote:
> > 
> > It's because the "fairness" bonus is still being done as a one shot 
> > bonus when a task's delay time become unfairly large.  I mentioned this 
> > before as possibly needing to be changed to a more persistent model but 
> > after I discovered the accounting bug I deferred doing anything about it 
> > in the hope that fixing the bug would have been sufficient.
> > 
> > I'll now try a model whereby a task's fairness bonus is increased 
> > whenever it has unfair delays and decreased when it doesn't.  Hopefully, 
> > with the right rates of increase/decrease, this can result in a system 
> > where a task has a fairly persistent bonus which is sufficient to give 
> > it its fair share.  One reason that I've been avoiding this method is 
> > that it introduces double smoothing: once in the calculation of the 
> > average delay time and then again in the determination of the bonus; and 
> > I'm concerned this may make it slow to react to change.  Any way I'll 
> > give it a try and see what happens.
> 
> Attached is a patch which makes the fairness bonuses more persistent.  I 
> should be applied on top of the last patch that I sent.  Could you test 
> it please?
> 

Sched Fooler
DD time: 16.1s --> 19.7s

Transcode:
DD time depends on the caching of the file DD is reading from (18.8s,
17.4s, ...)

DATA:

top - 18:12:04 up 9 min,  4 users,  load average: 2.94, 1.72, 0.73
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 46.2% us,  1.6% sy,  0.0% ni, 47.3% id,  4.8% wa,  0.0% hi,  0.1% si
Mem:    511168k total,   222908k used,   288260k free,     1608k buffers
Swap:  1004020k total,        0k used,  1004020k free,    61308k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 S 39.0  0.1   1:25.62 a.out
 5513 paolo     34   0  2392  288  228 R 32.2  0.1   1:25.12 a.out
 5514 paolo     34   0  2396  292  228 R 22.0  0.1   1:22.65 a.out
 5595 paolo     31   0  4952 1468  372 D  5.1  0.3   0:00.03 dd


top - 18:12:05 up 9 min,  4 users,  load average: 2.95, 1.74, 0.74
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.1% us,  1.9% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   251108k used,   260060k free,     1636k buffers
Swap:  1004020k total,        0k used,  1004020k free,    89472k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5514 paolo     34   0  2396  292  228 R 37.9  0.1   1:23.06 a.out
 5512 paolo     34   0  2392  288  228 S 31.5  0.1   1:25.96 a.out
 5513 paolo     34   0  2392  288  228 R 27.8  0.1   1:25.42 a.out
 5595 paolo     32   0  4952 1468  372 D  1.9  0.3   0:00.05 dd


top - 18:12:06 up 9 min,  4 users,  load average: 2.95, 1.74, 0.74
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 95.4% us,  3.7% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.9% si
Mem:    511168k total,   280028k used,   231140k free,     1664k buffers
Swap:  1004020k total,        0k used,  1004020k free,   118400k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 R 35.5  0.1   1:26.34 a.out
 5513 paolo     34   0  2392  288  228 S 34.6  0.1   1:25.79 a.out
 5514 paolo     34   0  2396  292  228 R 26.2  0.1   1:23.34 a.out
 5595 paolo     31   0  4952 1468  372 D  3.7  0.3   0:00.09 dd


top - 18:12:08 up 9 min,  4 users,  load average: 2.95, 1.74, 0.74
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.3% us,  3.7% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   308052k used,   203116k free,     1692k buffers
Swap:  1004020k total,        0k used,  1004020k free,   146304k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5514 paolo     34   0  2396  292  228 S 37.0  0.1   1:23.74 a.out
 5512 paolo     34   0  2392  288  228 R 33.3  0.1   1:26.70 a.out
 5513 paolo     34   0  2392  288  228 R 26.9  0.1   1:26.08 a.out
 5595 paolo     33   0  4952 1468  372 D  3.7  0.3   0:00.13 dd


top - 18:12:09 up 9 min,  4 users,  load average: 2.95, 1.74, 0.74
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.1% us,  2.9% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   336972k used,   174196k free,     1720k buffers
Swap:  1004020k total,        0k used,  1004020k free,   175232k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     34   0  2392  288  228 R 36.0  0.1   1:26.45 a.out
 5512 paolo     34   0  2392  288  228 R 30.2  0.1   1:27.01 a.out
 5514 paolo     33   0  2396  292  228 S 29.2  0.1   1:24.04 a.out
 5595 paolo     33   0  4952 1468  372 R  2.9  0.3   0:00.16 dd


top - 18:12:10 up 9 min,  4 users,  load average: 2.95, 1.74, 0.74
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 95.0% us,  4.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   360460k used,   150708k free,     1760k buffers
Swap:  1004020k total,        0k used,  1004020k free,   198788k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 R 39.1  0.1   1:27.40 a.out
 5513 paolo     34   0  2392  288  228 S 32.0  0.1   1:26.77 a.out
 5514 paolo     34   0  2396  292  228 R 26.0  0.1   1:24.30 a.out
 5595 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.20 dd


top - 18:12:11 up 9 min,  4 users,  load average: 3.03, 1.78, 0.76
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 94.0% us,  6.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   388000k used,   123168k free,     1784k buffers
Swap:  1004020k total,        0k used,  1004020k free,   226308k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5514 paolo     34   0  2396  292  228 R 34.0  0.1   1:24.64 a.out
 5512 paolo     34   0  2392  288  228 R 31.0  0.1   1:27.71 a.out
 5513 paolo     34   0  2392  288  228 R 29.0  0.1   1:27.06 a.out
 5595 paolo     31   0  4952 1468  372 D  6.0  0.3   0:00.26 dd


top - 18:12:12 up 9 min,  4 users,  load average: 3.03, 1.78, 0.76
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.1% us,  3.9% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   414640k used,    96528k free,     1812k buffers
Swap:  1004020k total,        0k used,  1004020k free,   252932k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     33   0  2392  288  228 S 34.3  0.1   1:27.41 a.out
 5514 paolo     34   0  2396  292  228 R 32.3  0.1   1:24.97 a.out
 5512 paolo     34   0  2392  288  228 R 30.4  0.1   1:28.02 a.out
 5595 paolo     34   0  4952 1468  372 R  3.9  0.3   0:00.30 dd


top - 18:12:13 up 9 min,  4 users,  load average: 3.03, 1.78, 0.76
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.0% us,  2.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   442244k used,    68924k free,     1836k buffers
Swap:  1004020k total,        0k used,  1004020k free,   280452k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 R 38.0  0.1   1:28.40 a.out
 5514 paolo     33   0  2396  292  228 S 31.0  0.1   1:25.28 a.out
 5513 paolo     34   0  2392  288  228 R 29.0  0.1   1:27.70 a.out
 5595 paolo     31   0  4952 1468  372 D  2.0  0.3   0:00.32 dd


top - 18:12:14 up 9 min,  4 users,  load average: 3.03, 1.78, 0.76
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.0% us,  2.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   468104k used,    43064k free,     1864k buffers
Swap:  1004020k total,        0k used,  1004020k free,   306308k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     34   0  2392  288  228 R 36.0  0.1   1:28.06 a.out
 5512 paolo     33   0  2392  288  228 R 33.0  0.1   1:28.73 a.out
 5514 paolo     34   0  2396  292  228 R 27.0  0.1   1:25.55 a.out
 5595 paolo     31   0  4952 1468  372 D  2.0  0.3   0:00.34 dd


top - 18:12:15 up 9 min,  4 users,  load average: 3.19, 1.83, 0.78
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.0% us,  3.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   494388k used,    16780k free,     1904k buffers
Swap:  1004020k total,        0k used,  1004020k free,   332424k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 S 36.0  0.1   1:29.09 a.out
 5514 paolo     34   0  2396  292  228 R 33.0  0.1   1:25.88 a.out
 5513 paolo     34   0  2392  288  228 R 29.0  0.1   1:28.35 a.out
 5595 paolo     33   0  4952 1468  372 D  4.0  0.3   0:00.38 dd


top - 18:12:16 up 9 min,  4 users,  load average: 3.19, 1.83, 0.78
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.0% us,  2.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   504828k used,     6340k free,     1096k buffers
Swap:  1004020k total,      200k used,  1003820k free,   343332k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     33   0  2392  288  228 R 35.0  0.1   1:28.70 a.out
 5512 paolo     34   0  2392  288  228 R 35.0  0.1   1:29.44 a.out
 5514 paolo     34   0  2396  292  228 R 28.0  0.1   1:26.16 a.out
 5595 paolo     31   0  4952 1468  372 D  2.0  0.3   0:00.40 dd


top - 18:12:17 up 9 min,  4 users,  load average: 3.19, 1.83, 0.78
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.0% us,  4.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   504692k used,     6476k free,     1108k buffers
Swap:  1004020k total,      200k used,  1003820k free,   343348k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     33   0  2392  288  228 S 34.0  0.1   1:29.04 a.out
 5512 paolo     34   0  2392  288  228 R 31.0  0.1   1:29.75 a.out
 5514 paolo     34   0  2396  292  228 R 30.0  0.1   1:26.46 a.out
 5595 paolo     32   0  4952 1468  372 D  4.0  0.3   0:00.44 dd


top - 18:12:18 up 9 min,  4 users,  load average: 3.19, 1.83, 0.78
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.0% us,  2.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   504692k used,     6476k free,     1116k buffers
Swap:  1004020k total,      200k used,  1003820k free,   343368k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5514 paolo     33   0  2396  292  228 R 38.0  0.1   1:26.84 a.out
 5512 paolo     34   0  2392  288  228 R 37.0  0.1   1:30.12 a.out
 5513 paolo     33   0  2392  288  228 R 24.0  0.1   1:29.28 a.out
 5595 paolo     31   0  4952 1468  372 D  1.0  0.3   0:00.45 dd


top - 18:12:19 up 9 min,  4 users,  load average: 3.19, 1.83, 0.78
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 96.0% us,  4.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505428k used,     5740k free,     1128k buffers
Swap:  1004020k total,      200k used,  1003820k free,   344152k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     34   0  2392  288  228 R 36.0  0.1   1:29.64 a.out
 5514 paolo     34   0  2396  292  228 R 32.0  0.1   1:27.16 a.out
 5512 paolo     33   0  2392  288  228 R 26.0  0.1   1:30.38 a.out
 5595 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.49 dd


top - 18:12:20 up 9 min,  4 users,  load average: 3.25, 1.86, 0.80
Tasks:   4 total,   4 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.0% us,  3.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505428k used,     5740k free,     1136k buffers
Swap:  1004020k total,      200k used,  1003820k free,   344180k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 R 40.0  0.1   1:30.78 a.out
 5513 paolo     34   0  2392  288  228 R 38.0  0.1   1:30.02 a.out
 5514 paolo     33   0  2396  292  228 R 21.0  0.1   1:27.37 a.out
 5595 paolo     33   0  4952 1468  372 R  3.0  0.3   0:00.52 dd


top - 18:12:21 up 9 min,  4 users,  load average: 3.25, 1.86, 0.80
Tasks:   4 total,   2 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 94.0% us,  5.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505484k used,     5684k free,     1152k buffers
Swap:  1004020k total,      200k used,  1003820k free,   344196k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5514 paolo     34   0  2396  292  228 R 45.0  0.1   1:27.82 a.out
 5512 paolo     34   0  2392  288  228 R 27.0  0.1   1:31.05 a.out
 5513 paolo     34   0  2392  288  228 S 22.0  0.1   1:30.24 a.out
 5595 paolo     31   0  4952 1468  372 D  5.0  0.3   0:00.57 dd


top - 18:12:22 up 9 min,  4 users,  load average: 3.25, 1.86, 0.80
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 94.0% us,  6.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505500k used,     5668k free,     1148k buffers
Swap:  1004020k total,      200k used,  1003820k free,   344228k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5512 paolo     34   0  2392  288  228 R 38.0  0.1   1:31.43 a.out
 5513 paolo     34   0  2392  288  228 R 32.0  0.1   1:30.56 a.out
 5514 paolo     33   0  2396  292  228 R 25.0  0.1   1:28.07 a.out
 5595 paolo     31   0  4952 1468  372 D  5.0  0.3   0:00.62 dd


top - 18:12:23 up 9 min,  4 users,  load average: 3.25, 1.86, 0.80
Tasks:   4 total,   3 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 93.9% us,  6.1% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   504948k used,     6220k free,     1156k buffers
Swap:  1004020k total,      200k used,  1003820k free,   343736k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5513 paolo     34   0  2392  288  228 R 34.0  0.1   1:30.90 a.out
 5512 paolo     34   0  2392  288  228 R 30.0  0.1   1:31.73 a.out
 5514 paolo     34   0  2396  292  228 R 28.0  0.1   1:28.35 a.out
 5595 paolo     31   0  4952 1468  372 D  6.0  0.3   0:00.68 dd


------------------------------------------------------------


top - 18:18:59 up 16 min,  4 users,  load average: 0.85, 1.06, 0.81
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 47.4% us,  1.5% sy,  0.0% ni, 46.8% id,  4.1% wa,  0.0% hi,  0.1% si
Mem:    511168k total,   378912k used,   132256k free,     1596k buffers
Swap:  1004020k total,      200k used,  1003820k free,   151740k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     32   0  116m  18m 2432 D 72.2  3.7   0:07.15 transcode
 5723 paolo     31   0  4952 1468  372 D  2.1  0.3   0:00.09 dd


top - 18:19:00 up 16 min,  4 users,  load average: 1.02, 1.09, 0.82
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 72.5% us,  5.9% sy,  0.0% ni,  0.0% id, 20.6% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   407952k used,   103216k free,     1632k buffers
Swap:  1004020k total,      200k used,  1003820k free,   180760k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     34   0  116m  18m 2432 D 64.4  3.7   0:07.81 transcode
 5723 paolo     31   0  4952 1468  372 D  4.9  0.3   0:00.14 dd


top - 18:19:01 up 16 min,  4 users,  load average: 1.02, 1.09, 0.82
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 59.4% us,  5.0% sy,  0.0% ni,  0.0% id, 33.7% wa,  0.0% hi,  2.0% si
Mem:    511168k total,   435152k used,    76016k free,     1664k buffers
Swap:  1004020k total,      200k used,  1003820k free,   208128k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     32   0  116m  18m 2432 D 55.3  3.7   0:08.37 transcode
 5723 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.18 dd


top - 18:19:02 up 16 min,  4 users,  load average: 1.02, 1.09, 0.82
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 58.0% us,  6.0% sy,  0.0% ni,  0.0% id, 35.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   461796k used,    49372k free,     1700k buffers
Swap:  1004020k total,      200k used,  1003820k free,   234656k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 D 45.0  3.7   0:08.82 transcode
 5723 paolo     31   0  4952 1468  372 D  3.0  0.3   0:00.21 dd


top - 18:19:03 up 16 min,  4 users,  load average: 1.02, 1.09, 0.82
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 56.4% us,  3.0% sy,  0.0% ni,  0.0% id, 40.6% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   482260k used,    28908k free,     1720k buffers
Swap:  1004020k total,      200k used,  1003820k free,   255160k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     31   0  116m  18m 2432 D 52.0  3.7   0:09.34 transcode
 5723 paolo     31   0  4952 1468  372 D  1.0  0.3   0:00.22 dd


top - 18:19:04 up 16 min,  4 users,  load average: 1.02, 1.09, 0.82
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 58.0% us,  7.0% sy,  0.0% ni,  0.0% id, 34.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   504828k used,     6340k free,     1680k buffers
Swap:  1004020k total,      200k used,  1003820k free,   277732k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     32   0  116m  18m 2432 D 54.0  3.7   0:09.88 transcode
 5723 paolo     31   0  4952 1468  372 D  7.0  0.3   0:00.29 dd


top - 18:19:05 up 16 min,  4 users,  load average: 1.10, 1.10, 0.83
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 69.7% us,  5.1% sy,  0.0% ni,  0.0% id, 25.3% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505216k used,     5952k free,     1108k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278812k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 D 66.0  3.7   0:10.54 transcode
 5723 paolo     31   0  4952 1468  372 D  3.0  0.3   0:00.32 dd


top - 18:19:06 up 16 min,  4 users,  load average: 1.10, 1.10, 0.83
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 62.0% us,  9.0% sy,  0.0% ni,  0.0% id, 28.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505276k used,     5892k free,     1068k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278936k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     34   0  116m  18m 2432 R 58.0  3.7   0:11.12 transcode
 5723 paolo     31   0  4952 1468  372 D  9.0  0.3   0:00.41 dd


top - 18:19:07 up 16 min,  4 users,  load average: 1.10, 1.10, 0.83
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 58.4% us,  5.9% sy,  0.0% ni,  0.0% id, 34.7% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505680k used,     5488k free,     1068k buffers
Swap:  1004020k total,      200k used,  1003820k free,   279300k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 D 53.0  3.7   0:11.65 transcode
 5723 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.45 dd


top - 18:19:08 up 16 min,  4 users,  load average: 1.10, 1.10, 0.83
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 48.0% us,  6.0% sy,  0.0% ni,  0.0% id, 45.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505276k used,     5892k free,     1092k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278920k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     31   0  116m  18m 2432 D 44.8  3.7   0:12.10 transcode
 5723 paolo     31   0  4952 1468  372 D  3.0  0.3   0:00.48 dd


top - 18:19:09 up 16 min,  4 users,  load average: 1.10, 1.10, 0.83
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 55.2% us,  3.8% sy,  0.0% ni,  0.0% id, 40.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505156k used,     6012k free,     1092k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278888k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     31   0  116m  18m 2432 D 50.3  3.7   0:12.63 transcode
 5723 paolo     31   0  4952 1468  372 D  3.8  0.3   0:00.52 dd


top - 18:19:10 up 16 min,  4 users,  load average: 1.25, 1.14, 0.84
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.0% us,  8.0% sy,  0.0% ni,  0.0% id, 25.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   504992k used,     6176k free,     1100k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278644k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 D 60.1  3.7   0:13.23 transcode
 5723 paolo     32   0  4952 1468  372 D  4.0  0.3   0:00.56 dd


top - 18:19:11 up 16 min,  4 users,  load average: 1.25, 1.14, 0.84
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 50.0% us,  6.0% sy,  0.0% ni,  0.0% id, 43.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505404k used,     5764k free,     1112k buffers
Swap:  1004020k total,      200k used,  1003820k free,   279148k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     32   0  116m  18m 2432 R 49.0  3.7   0:13.72 transcode
 5723 paolo     31   0  4952 1468  372 D  5.0  0.3   0:00.61 dd


top - 18:19:12 up 16 min,  4 users,  load average: 1.25, 1.14, 0.84
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 81.0% us,  7.0% sy,  0.0% ni,  0.0% id, 11.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   505056k used,     6112k free,     1116k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278640k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 R 74.0  3.7   0:14.46 transcode
 5723 paolo     31   0  4952 1468  372 D  3.0  0.3   0:00.64 dd


top - 18:19:13 up 16 min,  4 users,  load average: 1.25, 1.14, 0.84
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 95.0% us,  5.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505580k used,     5588k free,     1072k buffers
Swap:  1004020k total,      200k used,  1003820k free,   279348k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     34   0  116m  18m 2432 R 89.0  3.7   0:15.35 transcode
 5723 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.68 dd


top - 18:19:14 up 16 min,  4 users,  load average: 1.25, 1.14, 0.84
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 93.0% us,  6.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:    511168k total,   504852k used,     6316k free,     1088k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278640k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     34   0  116m  18m 2432 R 88.0  3.7   0:16.23 transcode
 5723 paolo     32   0  4952 1468  372 D  4.0  0.3   0:00.72 dd


top - 18:19:15 up 16 min,  4 users,  load average: 1.39, 1.17, 0.85
Tasks:   2 total,   2 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s): 91.0% us,  8.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  1.0% hi,  0.0% si
Mem:    511168k total,   504860k used,     6308k free,     1116k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278604k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     33   0  116m  18m 2432 R 83.0  3.7   0:17.06 transcode
 5723 paolo     33   0  4952 1468  372 R  5.0  0.3   0:00.77 dd


top - 18:19:16 up 16 min,  4 users,  load average: 1.39, 1.17, 0.85
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 94.0% us,  6.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    511168k total,   505100k used,     6068k free,     1144k buffers
Swap:  1004020k total,      200k used,  1003820k free,   278932k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5700 paolo     34   0  116m  18m 2432 R 86.0  3.7   0:17.92 transcode
 5723 paolo     31   0  4952 1468  372 D  4.0  0.3   0:00.81 dd


-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Sun, 22 Jan 2006 10:06:43 +1100
Peter Williams <pwil3058@bigpond.net.au> wrote:

> > ---- spa_ebs: great! (as expected)
> > 
> > (sched_fooler)
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  5418 paolo     34   0  2392  288  228 R 51.4  0.1   1:06.47 a.out
> >  5419 paolo     34   0  2392  288  228 R 43.7  0.1   0:54.60 a.out
> >  5448 paolo     11   0  4952 1468  372 D  3.0  0.3   0:00.12 dd
> > 
> > (transcode)
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  5456 paolo     34   0  115m  18m 2432 R 51.9  3.7   0:23.34 transcode
> >  5470 paolo     12   0 51000 4472 1872 S  5.7  0.9   0:02.38 tcdecode
> >  5480 paolo     11   0  4948 1468  372 D  3.5  0.3   0:00.33 dd
> > 
> > Very good DD test performance in both cases.
> 
> Good.  How do you find the interactive responsiveness with this one?

It seems geneally good.

However I've noticed that priority of X fluctuate a lot for unknown
reasons...

When doing almost nothing it gets prio 6/7 but if I only move the
cursor a bit it jumps up to ~29. 

If I'm running glxgears (with diret rendering ON) the priority stay to
6/7 and moving the cursor I'm only able to get priority 8.

Under load X priority goes up and it suffers (cursor jumps a bit).

IOW: strangeness!

-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Lee Revell]

On Mon, 2006-01-23 at 21:09 +0100, Paolo Ornati wrote:
> However I've noticed that priority of X fluctuate a lot for unknown
> reasons...
> 
> When doing almost nothing it gets prio 6/7 but if I only move the
> cursor a bit it jumps up to ~29. 
> 
> If I'm running glxgears (with diret rendering ON) the priority stay to
> 6/7 and moving the cursor I'm only able to get priority 8.
> 
> Under load X priority goes up and it suffers (cursor jumps a bit).
> 
> IOW: strangeness! 

This seems right to me, how do you expect X to be treated by the
scheduler?

Lee

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Mon, 23 Jan 2006 15:25:37 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> This seems right to me, how do you expect X to be treated by the
> scheduler?

Why moving the mouse a little (that causes a microscopic % of CPU
being used) makes X priority jump up to 29 from 6/7 ???

And why this doesn't happen when glxgears (for example) is running?
(under cpu load this is different, with X never getting "good"
priority -- if I remember correctly)

Maybe this is normal and depends on the way X sleeps or something...

I don't know much about schedulers but if I'm able to make the cursor
going in jerks with just a bit of CPU load (linux$ make -j16, for
example) I wonder why X cannot get a better priority...

-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Lee Revell]

On Mon, 2006-01-23 at 21:52 +0100, Paolo Ornati wrote:
> On Mon, 23 Jan 2006 15:25:37 -0500
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > This seems right to me, how do you expect X to be treated by the
> > scheduler?
> 
> Why moving the mouse a little (that causes a microscopic % of CPU
> being used) makes X priority jump up to 29 from 6/7 ???

> And why this doesn't happen when glxgears (for example) is running?
> (under cpu load this is different, with X never getting "good"
> priority -- if I remember correctly)
> 
> Maybe this is normal and depends on the way X sleeps or something...
> 

Because the scheduler favors interactive tasks (aka those which spend a
large % of time waiting on external events) and X is only considered
interactive when the mouse is being moved.  When glxgears is running
it's CPU bound and is therefore penalized.

> I don't know much about schedulers but if I'm able to make the cursor
> going in jerks with just a bit of CPU load (linux$ make -j16, for
> example) I wonder why X cannot get a better priority...
> 

Personally I don't see how we can expect to deliver OSX-caliber
multimedia performance using only generalized heuristics in the
scheduler (other OSes use hooks into the scheduler for multimedia).  At
the very least it seems you need isochronous scheduling and a
multi-threaded X server.

Lee

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Paolo Ornati]

On Mon, 23 Jan 2006 15:59:38 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> > Maybe this is normal and depends on the way X sleeps or something...
> > 
> 
> Because the scheduler favors interactive tasks (aka those which spend a
> large % of time waiting on external events) and X is only considered
> interactive when the mouse is being moved.  When glxgears is running
> it's CPU bound and is therefore penalized.

??

The reverse... lower priority number means BETTER priority. So Actually
X is penalized when I'm moving the mouse.

And running "glxgears" doesn't make X CPU bounded if direct rendering
is enabled -- it is GPU bounded...

In fact I can run "glxgears" and still have 97% of IDLE CPU time.

-- 
	Paolo Ornati
	Linux 2.6.16-rc1-plugsched on x86_64

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Lee Revell]

On Mon, 2006-01-23 at 22:10 +0100, Paolo Ornati wrote:
> On Mon, 23 Jan 2006 15:59:38 -0500
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > > Maybe this is normal and depends on the way X sleeps or something...
> > > 
> > 
> > Because the scheduler favors interactive tasks (aka those which spend a
> > large % of time waiting on external events) and X is only considered
> > interactive when the mouse is being moved.  When glxgears is running
> > it's CPU bound and is therefore penalized.
> 
> ??
> 
> The reverse... lower priority number means BETTER priority. So Actually
> X is penalized when I'm moving the mouse.
> 
> And running "glxgears" doesn't make X CPU bounded if direct rendering
> is enabled -- it is GPU bounded...
> 
> In fact I can run "glxgears" and still have 97% of IDLE CPU time.
> 

Ah, never mind, I misread your report then, I was thinking in terms of
RT priorities...

Lee

Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1

[Peter Williams]

Paolo Ornati wrote:
> On Sun, 22 Jan 2006 10:06:43 +1100
> Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
> 
>>>---- spa_ebs: great! (as expected)
>>>
>>>(sched_fooler)
>>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>> 5418 paolo     34   0  2392  288  228 R 51.4  0.1   1:06.47 a.out
>>> 5419 paolo     34   0  2392  288  228 R 43.7  0.1   0:54.60 a.out
>>> 5448 paolo     11   0  4952 1468  372 D  3.0  0.3   0:00.12 dd
>>>
>>>(transcode)
>>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>> 5456 paolo     34   0  115m  18m 2432 R 51.9  3.7   0:23.34 transcode
>>> 5470 paolo     12   0 51000 4472 1872 S  5.7  0.9   0:02.38 tcdecode
>>> 5480 paolo     11   0  4948 1468  372 D  3.5  0.3   0:00.33 dd
>>>
>>>Very good DD test performance in both cases.
>>
>>Good.  How do you find the interactive responsiveness with this one?
> 
> 
> It seems geneally good.
> 
> However I've noticed that priority of X fluctuate a lot for unknown
> reasons...
> 
> When doing almost nothing it gets prio 6/7 but if I only move the
> cursor a bit it jumps up to ~29. 
> 
> If I'm running glxgears (with diret rendering ON) the priority stay to
> 6/7 and moving the cursor I'm only able to get priority 8.

This is a function of the "entitlement based" fairness part of the 
scheduler.  Conceptually, it allocates each SCHED_NORMAL task "shares" 
based on its nice value (19->1, 0->20, -20->420) and calculates an 
entitlement based on the ratio of a tasks shares and the total shares in 
play.  It then compares the task's recent average cpu usage rate with 
its entitlement and sets the dynamic priority so as to try and match the 
cpu usage rate to the entitlement.

To implement this concept efficiently (i.e. avoiding maths especially 
divides as much as possible) a slightly different approach is taken in 
practice.  For each run queue, a recent maximum average cpu usage rate 
per share for tasks on that queue (a yardstick) is kept and each tasks 
usage per share is compared to that.  If it is greater then it becomes 
the new yardstick and the task is given a base dynamic priority of 34 
and otherwise it is given a priority between 11 and 34 based in 
proportion to the ratio of its usage per share to the yardstick.

Tasks are also awarded an interactive bonus based on the amount of 
interactive sleeping that they've been doing recently and this is 
subtracted from the base priority.  The 11 point offset in the base 
priority is there to allow the bonus to be applied without encroaching 
on the RT priority range.

To cater for periods of inactivity the yardstick is decayed towards zero 
each tick.

In general, this means that the busiest task on the system (in terms of 
cpu usage per share) at any particular time will have a priority of (34 
- interactivity bonus) but when the system is idle this may not be the 
case if the yardstick had been quite high and hasn't yet decayed enough.

This is why when the system is idle the X priority jumps to 29 when you 
move the mouse as it is now the new yardstick even with a relatively low 
usage rate.  But when glxgears is running it becomes the yardstick with 
quite high cpu usage rate per share and when you move the mouse the X 
servers usage per share is still small compared to the yardstick so it 
retains a small priority value.

> 
> Under load X priority goes up and it suffers (cursor jumps a bit).
> 
> IOW: strangeness!
> 

I hope I've explained the strangeness :-) but I'm still concerned that 
the cursor is jumping a bit.  In general, the entitlement based 
mechanism is quite good for interactive response as most interactive 
tasks have very low CPU usage rates but under heavy load their usage 
rate per share can approach the yardstick (mainly because the yardstick 
tends to get smaller under load) so some help is required in the form of 
interactive bonuses.  It looks like this component still needs a little 
work.

One area that I'm looking at is reducing the time slice size for the 
first CPU run after a task is forked.  From the above it should be 
apparent that a task with recent average CPU usage rate of zero (such as 
a newly forked process) will get a priority of (11 - bonus).  This is 
usually a good thing as it means that these tasks have good latency but 
if they are CPU bound tasks they will block out most other runnable 
tasks for a full time slice which is quite long (120 msecs).  (The 
occasions where this effect would be most noticeable is when doing 
something like a kernel build where lots of CPU intensive tasks are 
being forked.)  Shortening this first time slice won't have much effect 
on non CPU intensive tasks as they would generally have voluntarily 
surrendered the CPU within in a few msecs anyway and it will allow the 
scheduler to give the CPU intensive tasks an appropriate priority early 
in their life.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce