* [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 @ 2006-01-19 21:45 Peter Williams 2006-01-21 6:48 ` Peter Williams 2006-01-21 10:46 ` Paolo Ornati 0 siblings, 2 replies; 20+ messages in thread From: Peter Williams @ 2006-01-19 21:45 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen, Paolo Ornati 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-19 21:45 [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 Peter Williams @ 2006-01-21 6:48 ` Peter Williams 2006-01-21 10:46 ` Paolo Ornati 1 sibling, 0 replies; 20+ messages in thread From: Peter Williams @ 2006-01-21 6:48 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen, Paolo Ornati 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-19 21:45 [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 Peter Williams 2006-01-21 6:48 ` Peter Williams @ 2006-01-21 10:46 ` Paolo Ornati 2006-01-21 23:06 ` Peter Williams 1 sibling, 1 reply; 20+ messages in thread From: Paolo Ornati @ 2006-01-21 10:46 UTC (permalink / raw) To: Peter Williams Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-21 10:46 ` Paolo Ornati @ 2006-01-21 23:06 ` Peter Williams 2006-01-22 22:47 ` Peter Williams 2006-01-23 20:09 ` Paolo Ornati 0 siblings, 2 replies; 20+ messages in thread From: Peter Williams @ 2006-01-21 23:06 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-21 23:06 ` Peter Williams @ 2006-01-22 22:47 ` Peter Williams 2006-01-23 0:49 ` Peter Williams 2006-01-23 20:09 ` Paolo Ornati 1 sibling, 1 reply; 20+ messages in thread From: Peter Williams @ 2006-01-22 22:47 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-22 22:47 ` Peter Williams @ 2006-01-23 0:49 ` Peter Williams 2006-01-23 20:21 ` Paolo Ornati 0 siblings, 1 reply; 20+ messages in thread From: Peter Williams @ 2006-01-23 0:49 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen [-- 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); ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 0:49 ` Peter Williams @ 2006-01-23 20:21 ` Paolo Ornati 2006-01-24 0:00 ` Peter Williams 2006-01-26 1:09 ` Peter Williams 0 siblings, 2 replies; 20+ messages in thread From: Paolo Ornati @ 2006-01-23 20:21 UTC (permalink / raw) To: Peter Williams Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:21 ` Paolo Ornati @ 2006-01-24 0:00 ` Peter Williams 2006-01-26 1:09 ` Peter Williams 1 sibling, 0 replies; 20+ messages in thread From: Peter Williams @ 2006-01-24 0:00 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:21 ` Paolo Ornati 2006-01-24 0:00 ` Peter Williams @ 2006-01-26 1:09 ` Peter Williams 2006-01-26 8:11 ` Paolo Ornati 1 sibling, 1 reply; 20+ messages in thread From: Peter Williams @ 2006-01-26 1:09 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen [-- 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, ¤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) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-26 1:09 ` Peter Williams @ 2006-01-26 8:11 ` Paolo Ornati 2006-01-26 22:34 ` Peter Williams 0 siblings, 1 reply; 20+ messages in thread From: Paolo Ornati @ 2006-01-26 8:11 UTC (permalink / raw) To: Peter Williams Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-26 8:11 ` Paolo Ornati @ 2006-01-26 22:34 ` Peter Williams 2006-01-28 23:44 ` Peter Williams 0 siblings, 1 reply; 20+ messages in thread From: Peter Williams @ 2006-01-26 22:34 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-26 22:34 ` Peter Williams @ 2006-01-28 23:44 ` Peter Williams 2006-01-31 17:44 ` Paolo Ornati 0 siblings, 1 reply; 20+ messages in thread From: Peter Williams @ 2006-01-28 23:44 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen [-- 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) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-28 23:44 ` Peter Williams @ 2006-01-31 17:44 ` Paolo Ornati 0 siblings, 0 replies; 20+ messages in thread From: Paolo Ornati @ 2006-01-31 17:44 UTC (permalink / raw) To: Peter Williams Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-21 23:06 ` Peter Williams 2006-01-22 22:47 ` Peter Williams @ 2006-01-23 20:09 ` Paolo Ornati 2006-01-23 20:25 ` Lee Revell 2006-01-23 23:32 ` Peter Williams 1 sibling, 2 replies; 20+ messages in thread From: Paolo Ornati @ 2006-01-23 20:09 UTC (permalink / raw) To: Peter Williams Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:09 ` Paolo Ornati @ 2006-01-23 20:25 ` Lee Revell 2006-01-23 20:52 ` Paolo Ornati 2006-01-23 23:32 ` Peter Williams 1 sibling, 1 reply; 20+ messages in thread From: Lee Revell @ 2006-01-23 20:25 UTC (permalink / raw) To: Paolo Ornati Cc: Peter Williams, Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:25 ` Lee Revell @ 2006-01-23 20:52 ` Paolo Ornati 2006-01-23 20:59 ` Lee Revell 0 siblings, 1 reply; 20+ messages in thread From: Paolo Ornati @ 2006-01-23 20:52 UTC (permalink / raw) To: Lee Revell Cc: Peter Williams, Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:52 ` Paolo Ornati @ 2006-01-23 20:59 ` Lee Revell 2006-01-23 21:10 ` Paolo Ornati 0 siblings, 1 reply; 20+ messages in thread From: Lee Revell @ 2006-01-23 20:59 UTC (permalink / raw) To: Paolo Ornati Cc: Peter Williams, Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:59 ` Lee Revell @ 2006-01-23 21:10 ` Paolo Ornati 2006-01-23 21:11 ` Lee Revell 0 siblings, 1 reply; 20+ messages in thread From: Paolo Ornati @ 2006-01-23 21:10 UTC (permalink / raw) To: Lee Revell Cc: Peter Williams, Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 21:10 ` Paolo Ornati @ 2006-01-23 21:11 ` Lee Revell 0 siblings, 0 replies; 20+ messages in thread From: Lee Revell @ 2006-01-23 21:11 UTC (permalink / raw) To: Paolo Ornati Cc: Peter Williams, Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 2006-01-23 20:09 ` Paolo Ornati 2006-01-23 20:25 ` Lee Revell @ 2006-01-23 23:32 ` Peter Williams 1 sibling, 0 replies; 20+ messages in thread From: Peter Williams @ 2006-01-23 23:32 UTC (permalink / raw) To: Paolo Ornati Cc: Linux Kernel Mailing List, Chris Han, Con Kolivas, William Lee Irwin III, Jake Moilanen 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2006-01-31 17:44 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-19 21:45 [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1 Peter Williams 2006-01-21 6:48 ` Peter Williams 2006-01-21 10:46 ` Paolo Ornati 2006-01-21 23:06 ` Peter Williams 2006-01-22 22:47 ` Peter Williams 2006-01-23 0:49 ` Peter Williams 2006-01-23 20:21 ` Paolo Ornati 2006-01-24 0:00 ` Peter Williams 2006-01-26 1:09 ` Peter Williams 2006-01-26 8:11 ` Paolo Ornati 2006-01-26 22:34 ` Peter Williams 2006-01-28 23:44 ` Peter Williams 2006-01-31 17:44 ` Paolo Ornati 2006-01-23 20:09 ` Paolo Ornati 2006-01-23 20:25 ` Lee Revell 2006-01-23 20:52 ` Paolo Ornati 2006-01-23 20:59 ` Lee Revell 2006-01-23 21:10 ` Paolo Ornati 2006-01-23 21:11 ` Lee Revell 2006-01-23 23:32 ` Peter Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).