From: Borislav Petkov <bp@alien8.de>
To: Len Brown <lenb@kernel.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Renninger <trenn@suse.com>,
Kan Liang <kan.liang@intel.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [RFC PATCH] x86: Move away from /dev/cpu/*/msr
Date: Wed, 15 Jun 2016 19:39:26 +0200 [thread overview]
Message-ID: <20160615173926.GD30309@pd.tnic> (raw)
In-Reply-To: <CAJvTdKnDUDXwmj_Yy=Z-ScugHX_2sHtijk7WESWc26rNqPzGpQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-06-15 17:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 10:00 [RFC PATCH] x86: Move away from /dev/cpu/*/msr Borislav Petkov
2016-06-15 10:22 ` chenyu
2016-06-15 10:36 ` Borislav Petkov
2016-06-15 14:00 ` Borislav Petkov
2016-06-15 16:41 ` Len Brown
2016-06-15 16:56 ` Borislav Petkov
2016-06-15 17:21 ` Len Brown
2016-06-15 17:39 ` Borislav Petkov [this message]
2016-06-15 17:42 ` Len Brown
2016-06-15 17:52 ` Borislav Petkov
2016-06-20 21:12 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160615173926.GD30309@pd.tnic \
--to=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=kan.liang@intel.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=tglx@linutronix.de \
--cc=trenn@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).