Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754652AbcKIWZD (ORCPT ); Wed, 9 Nov 2016 17:25:03 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:59400 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753199AbcKIWZC (ORCPT ); Wed, 9 Nov 2016 17:25:02 -0500 Date: Wed, 9 Nov 2016 23:21:11 +0100 (CET) From: Thomas Gleixner To: "Andrejczuk, Grzegorz" cc: "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "bp@suse.de" , "dave.hansen@linux.intel.com" , "Daniluk, Lukasz" , "Cownie, James H" , "Pan, Jacob jun" , "Luc, Piotr" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing In-Reply-To: Message-ID: References: <1478699194-30946-1-git-send-email-grzegorz.andrejczuk@intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1703 Lines: 49 On Wed, 9 Nov 2016, Andrejczuk, Grzegorz wrote: > -----Original Message----- > From: Thomas Gleixner [mailto:tglx@linutronix.de] Can you pretty please use a mail client which does not copy the whole mail header into the mail body? That's just annoying. > Sorry we end up in this situation. > > I have removed PHI from: > - MSR definition, > - HWCAP2 bit, > - X86_CPU_FEATURE > > Making kernel parameter non-phi would require implementing the > ring3mwait=disable for any other non-ring 0 MWAIT (i.e AMD MWAITX). No, it would not. Simply because AMD does not yet provide any means to enable ring3 MWAIT in the kernel and adding this parameter does not require to implement it at all. There are gazillions of generic kernel parameters which are only effective on particular systems. They describe a general feature not a particular implementation. If that support for AMD gets ever implemented then it definitely wants to reuse ring3wait and not phiring3mwait and neiter it wants to add amdF16ring3mwait.. That feature is going to show up on other Intel cpus sooner than later. Are we supposed to have xeonring3mwait and atomring3mwait command line options as well? Can you see how that gets silly very fast? > My concern is that kernel will have to maintain various non architectural > model specific stuff in single kernel parameter. The feature of enabling ring3 mwait is the same whether it's on PHI, xeon, atom or some AMD model. Why on earth should they use a different parameter? If you think I'm wrong, then discuss that instead of silently ignoring my review requests and resending the same stuff over and over. We could have been done with that thing weeks ago. Thanks, tglx