Re: bltk-game regressions on snb laptop

[Arjan van de Ven <arjan@linux.intel.com>]

>
> So you get better performance without my patch because we don't allocate
> any struct cpufreq_policy for any of the cpus leaving first one. And so only
> manage freq change for it and all other cpus stay at max power..
>
> So, we clearly need to know why don't we want to have all cpus set in
> policy->cpus, when they actually share clock line?
>

right conclusion, wrong solution ;-)

Alex should know by now (we told him this internally quite a few times) that this indeed is happening.
But the answer is not to try to make the software know that things share a clock line,
the answer is that the current code is correct.

(on x86, the way shared voltage/frequency domains work is that the current clock value is the maximum of
what the individual *non idle* cpu's asked for. If the cpu asking for the highest value goes idle,
all others will drop their frequency to the value the next highest is asking for, etc.
Trying to do this kind of thing in software is backwards and actually ends up burning a lot of power)


on the 'regression'; of COURSE things might go slower once you stop acting like the "performance" governor.
now, ondemand is pretty dire for this generation of hardware, and that's why we have asked Alex repeatedly
to actually use the driver Intel has gotten upstream for this generation of hardware instead.
I do not know why he has not done that instead of trying to get a bug put back into the kernel.