Received: by 10.213.65.68 with SMTP id h4csp138195imn; Fri, 30 Mar 2018 02:34:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx49w/gnH4f2NX3JHBbbvDFccmLEy3v6prYeAuiJLGyZFgBmwtC/chN4jpFXezSLb0d2U3Q+T X-Received: by 10.98.181.18 with SMTP id y18mr9305678pfe.115.1522402457279; Fri, 30 Mar 2018 02:34:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522402457; cv=none; d=google.com; s=arc-20160816; b=Iy6VPcMcqiqNjnucagcleFOZZ1VM0gllRTRR3zRTBwS0PN2GQnYFGxGdnW1LV2VNQh UdByNL9uFNxt1hDjnUvPMNrGuZBcaDa8q/n6ssEyq+X9Stvdvwv8kghrtqsvSGbLwadU DG/6Ooh1h0pRzZXntJpTa4/0Hp1oplF86Db7qZQN4WWHRTiudEjqwrj2dYrH9Sl2GVJd 49fyhgCEhLYfGkKPdoM0bAJ67ngRRC8fh477qwMG0W/Jis0lDQdwCfuAUyLoehUjhOpq S4mLva9OiRB2tXcN3SO/jx9bdT/hLgmxYK2etzDX1ZKYZRaW5COMI9Jil0lgg6Umxm9s BvPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=XPgjV+tReLHjnj7VMZUNK0ehEnXYr8I9zO48GDnhvOs=; b=smIQ8YirbxAcfDpjc7jO+6rSrel9f35fWwt4pVy1QhxlqoSf1o8E3KshC7b56L1eLZ KmkhGuP/r3qBr8up7Q/cw5FnK/XfXdPX9twjUAB/mmfGdczfpXIkdQK0oj05CQfy3+qg ctqdNQxBnJrzpys3OB4pC+PTTVj34/Q1npgX3XJ48umm4eL2mgLZbgvNfqlP5cB+m7DO 7RcTRBfOXVmVv7c5AnfR6SE+ymD9oHXVl4shINjnMs9uw+Dla+7b3ffFx5xF2G2UDYmX HtN8rmLbdwXuidA/Vo2dOsXVnC7XDg+iBx6WK7/SvO7TAIFcBgkkDFHQ5X5jv/NyJnOm 6nMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e16si6185626pfd.6.2018.03.30.02.34.03; Fri, 30 Mar 2018 02:34:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751290AbeC3Jcu (ORCPT + 99 others); Fri, 30 Mar 2018 05:32:50 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55548 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751129AbeC3Jcs (ORCPT ); Fri, 30 Mar 2018 05:32:48 -0400 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f1qOf-0000cx-37; Fri, 30 Mar 2018 11:32:33 +0200 Date: Fri, 30 Mar 2018 11:32:29 +0200 (CEST) From: Thomas Gleixner To: Vikas Shivappa cc: vikas.shivappa@intel.com, tony.luck@intel.com, ravi.v.shankar@intel.com, fenghua.yu@intel.com, sai.praneeth.prakhya@intel.com, x86@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org, ak@linux.intel.com Subject: Re: [PATCH 2/6] x86/intel_rdt/mba_sc: Add support to enable/disable via mount option In-Reply-To: <1522362376-3505-3-git-send-email-vikas.shivappa@linux.intel.com> Message-ID: References: <1522362376-3505-1-git-send-email-vikas.shivappa@linux.intel.com> <1522362376-3505-3-git-send-email-vikas.shivappa@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Mar 2018, Vikas Shivappa wrote: Subject: x86/intel_rdt/mba_sc: Add support to enable/disable via mount option Huch? From Documentation: The ``summary phrase`` in the email's Subject should concisely describe the patch which that email contains. You're introducing somthing new: mba_sc It's completely unclear what that is and what it means. x86/intel_rdt: Add mount option for bandwidth allocation in MB/s or something like that. > Specify a new mount option "mba_MB" to enable the user to specify MBA > bandwidth in Megabytes(Software Controller/SC) instead of b/w You cannot specify bandwidth in Megabytes. Bandwidth is a bit-rate and the units are multiples of bits per second and not Megabytes. > --- a/arch/x86/kernel/cpu/intel_rdt.h > +++ b/arch/x86/kernel/cpu/intel_rdt.h > @@ -259,6 +259,7 @@ struct rdt_cache { > * @min_bw: Minimum memory bandwidth percentage user can request > * @bw_gran: Granularity at which the memory bandwidth is allocated > * @delay_linear: True if memory B/W delay is in linear scale > + * @bw_byte: True if memory B/W is specified in bytes So the mount parameter says Megabytes, but here you say bytes? What? And bw_byte is a misnomer. bw_bytes if you really mean bytes. bw_mb if it's megabytes. > +#define is_mba_linear() rdt_resources_all[RDT_RESOURCE_MBA].membw.delay_linear > +#define is_mba_MBctrl() rdt_resources_all[RDT_RESOURCE_MBA].membw.bw_byte Please use inlines and no camel case. That's horrible. > + > /** > * struct rdt_resource - attributes of an RDT resource > * @rid: The index of the resource > diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c > index fca759d..0707191 100644 > --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c > +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c > @@ -1041,6 +1041,24 @@ static int set_cache_qos_cfg(int level, bool enable) > return 0; > } > > +static void __set_mba_byte_ctrl(bool byte_ctrl) > +{ > + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_MBA]; > + > + r->membw.bw_byte = byte_ctrl; I don't see the point of this extra function. It has exactly one user. > +} > + > +/* > + * MBA allocation in bytes is only supported if > + * MBM is supported and MBA is in linear scale. > +*/ Hint: checkpatch.pl is not optional > +static void set_mba_byte_ctrl(bool byte_ctrl) > +{ > + if ((is_mbm_enabled() && is_mba_linear()) && > + byte_ctrl != is_mba_MBctrl()) > + __set_mba_byte_ctrl(byte_ctrl); And that user is a small enough function. To avoid indentation you can simply return when the condition is false. Also if the user wants to mount with the MB option and it's not supported, why are you not returning an error code and refuse the mount? That's just wrong. > + > static int cdp_enable(int level, int data_type, int code_type) > { > struct rdt_resource *r_ldata = &rdt_resources_all[data_type]; > @@ -1104,7 +1122,7 @@ static void cdp_disable_all(void) > cdpl2_disable(); > } > > -static int parse_rdtgroupfs_options(char *data) > +static int parse_rdtgroupfs_options(char *data, bool *mba_MBctrl) What? > { > char *token, *o = data; > int ret = 0; > @@ -1123,6 +1141,8 @@ static int parse_rdtgroupfs_options(char *data) > ret = cdpl2_enable(); > if (ret) > goto out; > + } else if (!strcmp(token, "mba_MB")) { > + *mba_MBctrl = true; That's mindless hackery. Really. What's wrong with setting the flag in the resource and then add the actual register fiddling right in the if (is_mbm_enabled()) { section in rdt_mount()? That would be too obvious and fit into the existing code, right? > + /*Set the control values before the rest of reset*/ Space after '/*' and before '*/ Aside of that the comment is pretty useless. 'the control values' ??? Which control values? > + set_mba_byte_ctrl(false); Thanks, tglx