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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Fri, 20 Jan 2006 08:45:43 +1100
Peter Williams <[email protected]> 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
Paolo Ornati wrote:
> On Fri, 20 Jan 2006 08:45:43 +1100
> Peter Williams <[email protected]> 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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Peter Williams wrote:
> Paolo Ornati wrote:
>
>> On Fri, 20 Jan 2006 08:45:43 +1100
>> Peter Williams <[email protected]> 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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
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);
On Sun, 22 Jan 2006 10:06:43 +1100
Peter Williams <[email protected]> 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
On Mon, 23 Jan 2006 11:49:33 +1100
Peter Williams <[email protected]> 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
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
On Mon, 23 Jan 2006 15:25:37 -0500
Lee Revell <[email protected]> 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
On Mon, 2006-01-23 at 21:52 +0100, Paolo Ornati wrote:
> On Mon, 23 Jan 2006 15:25:37 -0500
> Lee Revell <[email protected]> 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
On Mon, 23 Jan 2006 15:59:38 -0500
Lee Revell <[email protected]> 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
On Mon, 2006-01-23 at 22:10 +0100, Paolo Ornati wrote:
> On Mon, 23 Jan 2006 15:59:38 -0500
> Lee Revell <[email protected]> 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
Paolo Ornati wrote:
> On Sun, 22 Jan 2006 10:06:43 +1100
> Peter Williams <[email protected]> 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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Paolo Ornati wrote:
> On Mon, 23 Jan 2006 11:49:33 +1100
> Peter Williams <[email protected]> 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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
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, ¤t->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)
On Thu, 26 Jan 2006 12:09:53 +1100
Peter Williams <[email protected]> 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
Paolo Ornati wrote:
> On Thu, 26 Jan 2006 12:09:53 +1100
> Peter Williams <[email protected]> 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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
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)
On Sun, 29 Jan 2006 10:44:17 +1100
Peter Williams <[email protected]> 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