Re: [patch] sched: generic sched_group cpu power setup

[Paul Jackson <pj@sgi.com>]

> If any one has a better suggestion, I am open.

I'm still trying to figure out what the hell it is ;).

Sorry ... as my teenage son would gladly tell you, I can be dense
at times.

If all the CPUs in a system have the same computational capacity,
then is it just the number of CPUs in a group (times a scale factor
of 128, to simulate fixed point arithmetic with integers)?

I presume "yes", from such code lines as:

  power = SCHED_LOAD_SCALE * cpus_weight(sd->groups->cpumask);

If two CPUs, side by side, have the same computational capacity,
but one consumes more electrical power (watts) than the other, do they
have different cpu_power?

I presume "no" - electrical power consumption does not affect this value
(though some effort might be made to minimize electrical power consumption
in these calculations, by letting some CPUs go idle if the job mix allows
for that.)

If I presumed correctly, then apparently what we're talking about here
is computational capacity, as is typically measured in such units as
MIPS, megaflops/sec or Drystones. In other words, what Andrew termed
"computing power" when he fired the starter's pistol on this scrum.

Is that what this is -- computational capacity, aka computing power
(appropriately scaled for the convenience of the arithmetic)?

And is the unit of measure just the number of CPUs in the group
(times 128)?

If the above is accurate, then the group structure member could almost
be called "ncpus" (number of cpus in group), unscaled.  Perhaps you
only need to scale the value for fixed point arithmetic while calculating
what balancing to attempt.

One more  detail, as you likely already noticed, if you rename
"cpu_power" to not mention "power", then consider also the routine 
init_numa_sched_groups_power(), the variables pwr_now, pwr_move and
power, and the mentions of "power" in the comments.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401