From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753472AbcFORjj (ORCPT ); Wed, 15 Jun 2016 13:39:39 -0400 Received: from mail.skyhub.de ([78.46.96.112]:45090 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157AbcFORja (ORCPT ); Wed, 15 Jun 2016 13:39:30 -0400 Date: Wed, 15 Jun 2016 19:39:26 +0200 From: Borislav Petkov To: Len Brown Cc: lkml , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Greg Kroah-Hartman , Thomas Renninger , Kan Liang , "Peter Zijlstra (Intel)" , "Rafael J. Wysocki" , Len Brown , Linux PM list Subject: Re: [RFC PATCH] x86: Move away from /dev/cpu/*/msr Message-ID: <20160615173926.GD30309@pd.tnic> References: <20160615100029.GB32588@pd.tnic> <20160615165618.GF32588@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.