On Wed, Jun 15, 2016 at 01:21:01PM -0400, Len Brown wrote:
> The API -- the name -- must be clear about what MSR it talks to.
Didn't I say that?!
"Surely we can make the new interface work too - perhaps add a new sysfs
file for the new thing."
> I suggest that the name exactly match the name of the actual MSR,
> because you are about to need a 2nd one with a name so close
> that it will otherwise be ambiguous.
So from looking at IA32_HWP_REQUEST, it sounds like you'd need a whole
new dir:
hwp_req
|-> package_control
|-> energy_perf_pref
|-> ...
|-> min_perf
and both interfaces will be visible only when the CPUID bit is set.
I.e., for the energy_policy_pref_hint, I'm checking X86_FEATURE_EPB and
I'm sure the HWP ones have CPUID bits too.
> Again, I support your direction. I'm not trying to work against it,
> I'm trying to tell you that you are just scratching the surface
> and there will be more steps to complete the task -- because
> there are more MSRs.
Oh, I know that. That's why this is a first RFC, to poke at people.
Also, I'm looking at the WRMSR use cases first. The reading can be taken
care of later.
> Your new API doesn't exist on the installed base, and so the old
> /dev/msr method must be available to the installed base. Sure, in the
> future, when the new API is available, we can update the utility to
> use it going forward.
Well, since the utility is part of tools/, it goes with the kernel
version. Just like perf.
Or are you dying to be able to use new tool on old kernels?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
