From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932808AbcFOQ4Y (ORCPT ); Wed, 15 Jun 2016 12:56:24 -0400 Received: from mail.skyhub.de ([78.46.96.112]:45989 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752789AbcFOQ4W (ORCPT ); Wed, 15 Jun 2016 12:56:22 -0400 Date: Wed, 15 Jun 2016 18:56:18 +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: <20160615165618.GF32588@pd.tnic> References: <20160615100029.GB32588@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 12:41:21PM -0400, Len Brown wrote: > Recent hardware has an additional MSR field > > MSR_IA32_HWP_REQUEST.ENERGY_PERFORMANCE_PREFERENCE > that replaces > > MSR_IA32_ENERGY_PERF_BIAS > for the purpose of P-state control. > > > Both MSRs/fields exist and have effect at the same time. > > so the API > energy_policy_pref_hint > > will not work -- as it isn't clear which MSR it refers to. Surely we can make the new interface work too - perhaps add a new sysfs file for the new thing. The old MSR_IA32_ENERGY_PERF_BIAS would be needed on those older boxes. Or we can have a sysfs file which is called something like "perf_preference" or whatnot and that thing either maps input to the old MSR_IA32_ENERGY_PERF_BIAS or to the new thing. > I've updated x86_energy_perf_policy to talk to this MSR > and a number of others for the benefit of HWP. The > patch is over 1000 lines. I'll post it shortly. So we should *not* give ourselves the example that using msr.ko for other things *besides* debugging is ok. It is very wrong to talk to naked MSRs and we have done it by now because this thing was there and well, sure, why not use it. But poking at MSRs is dangerous and we need proper abstraction. And we should work towards that instead perpetuating wrong use. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.