On Sunday 15 January 2006 11:05, Peter Williams wrote: > Martin J. Bligh wrote: > >> Attached is a new patch to fix the excessive idle problem. This patch > >> takes a new approach to the problem as it was becoming obvious that > >> trying to alter the load balancing code to cope with biased load was > >> harder than it seemed. > >> > >> This approach reverts to the old load values but weights them > >> according to tasks' bias_prio values. This means that any assumptions > >> by the load balancing code that the load generated by a single task is > >> SCHED_LOAD_SCALE will still hold. Then, in find_busiest_group(), the > >> imbalance is scaled back up to bias_prio scale so that move_tasks() > >> can move biased load rather than tasks. > > > > OK, this one seems to fix the issue that I had, AFAICS. Congrats, and > > thanks, > > Terrific, thanks for testing. > > Con, > Attached is a cleaned up version of this patch against 2.6.15-mm4 with > some (hopefully helpful) comments added. One minor quibble. Cheers, Con --- These #defines have no cost on !CONFIG_SMP without the ifdefs. Remove the unnecessary ifdefs. Signed-off-by: Con Kolivas <[email protected]> kernel/sched.c | 2 -- 1 files changed, 2 deletions(-) Index: linux-2.6.15-mm4/kernel/sched.c =================================================================== --- linux-2.6.15-mm4.orig/kernel/sched.c +++ linux-2.6.15-mm4/kernel/sched.c @@ -63,7 +63,6 @@ #define PRIO_TO_NICE(prio) ((prio) - MAX_RT_PRIO - 20) #define TASK_NICE(p) PRIO_TO_NICE((p)->static_prio) -#ifdef CONFIG_SMP /* * Priority bias for load balancing ranges from 1 (nice==19) to 139 (RT * priority of 100). @@ -71,7 +70,6 @@ #define NICE_TO_BIAS_PRIO(nice) (20 - (nice)) #define PRIO_TO_BIAS_PRIO(prio) NICE_TO_BIAS_PRIO(PRIO_TO_NICE(prio)) #define RTPRIO_TO_BIAS_PRIO(rp) (40 + (rp)) -#endif /* * 'User priority' is the nice value converted to something we
Attachment:
pgpFNwrjlXObc.pgp
Description: PGP signature
- References:
- -mm seems significanty slower than mainline on kernbench
- From: Martin Bligh <[email protected]>
- Re: -mm seems significanty slower than mainline on kernbench
- From: "Martin J. Bligh" <[email protected]>
- Re: -mm seems significanty slower than mainline on kernbench
- From: Peter Williams <[email protected]>
- -mm seems significanty slower than mainline on kernbench
- Prev by Date: Re: -mm seems significanty slower than mainline on kernbench
- Next by Date: Suggested janitor task - remove __init/__exit from function prototypes
- Previous by thread: Re: -mm seems significanty slower than mainline on kernbench
- Next by thread: Re: -mm seems significanty slower than mainline on kernbench
- Index(es):
 |