Re: volanoMark regression with kernel 2.6.26-rc1

[Peter Zijlstra]

> +#define GROUP_SCALE	(2*1024)
> +
>  static inline void inc_cpu_load(struct rq *rq, unsigned long load)
>  {
> +	load *= GROUP_SCALE;
>  	update_load_add(&rq->load, load);
>  }
>  
>  static inline void dec_cpu_load(struct rq *rq, unsigned long load)
>  {
> +	load *= GROUP_SCALE;
>  	update_load_sub(&rq->load, load);
>  }


Yeah, this bit makes a huge difference; I do that by:

mkdir /cgroup/foo
for i in `cat /cgroup/tasks`; do echo $i > /cgroup/foo/tasks; done
echo $((1024*1024)) > /cgroup/foo/cpu.shares

I'm still pulling my hairs out on why this makes a difference though - I
eliminated all direct assumption on SCHED_LOAD_SCALE(_FUZZ) with an
average of the weight per task. - but all that doesn't help (much)

A few other things I found that make a significant difference:



+static void update_aggregate(int cpu, struct sched_domain *sd)
+{
+       aggregate_walk_tree(aggregate_get_down, aggregate_get_nop, cpu, sd);
+}


@@ -3224,6 +3189,8 @@ static int move_tasks(struct rq *this_rq, int this_cpu, st
ruct rq *busiest,
        unsigned long total_load_moved = 0;
        int this_best_prio = this_rq->curr->prio;

+       update_aggregate(this_cpu, sd);
+
        do {
                total_load_moved +=
                        class->load_balance(this_rq, this_cpu, busiest,



and

@@ -1169,7 +1168,10 @@ static unsigned long wakeup_gran(struct sched_entity *se)
         * More easily preempt - nice tasks, while not making it harder for
         * + nice tasks.
         */
-       gran = calc_delta_asym(sysctl_sched_wakeup_granularity, se);
+       if (sched_feat(ASYM_GRAN))
+               gran = calc_delta_asym(sysctl_sched_wakeup_granularity, se);
+       else
+               gran = calc_delta_fair(sysctl_sched_wakeup_granularity, se);

        return gran;
 }


the asym logic is wrong wrt shares - it should look at tg->weight

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/