sched: remove WARN_ON(!sd) from init_sched_groups_power()

sd can't be NULL in init_sched_groups_power() and so checking it for NULL isn't useful. In case it is required, then also we need to rearrange the code a bit as we already accessed invalid pointer sd to get sg: sg = sd->groups.
sched: reduce calculation effort in fix_small_imbalance

Actually all below item could be repalced by scaled_busy_load_per_task
	(sds->busiest_load_per_task * SCHED_POWER_SCALE)
		/sds->busiest->sgp->power;
sched: scale the busy and this queue's per-task load before compare

Since for max_load and this_load, they are the value that already be scaled. It is not reasonble to get a minimum value between the scaled and non-scaled value, like below example.
	min(sds->busiest_load_per_task, sds->max_load);

Also add comment over in what condition, there would be cpu power gain in move the load.
sched: scale cpu load for judgment of group imbalance

We cannot compare two load directly from two cpus, since the cpu power over two cpu may vary largely.

Suppose we meet such two kind of cpus.
CPU A:
	No real time work, and there are 3 task, with rq->load.weight being 512.
CPU B:
	Has real time work, and it take 3/4 of the cpu power, which makes CFS only take 1/4, that is 1024/4=256 cpu power. And over its CFS runqueue, there is only one task with weight as 128.

Since both cpu's CFS task take for half of the CFS's cpu power, it should be considered as balanced in such case.

But original judgment like:
        if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
            (max_nr_running - min_nr_running) > 1)
It makes (512-128)>=((512+128)/4), and lead to imbalance conclusion...
Make the load as scaled, to avoid such case.