From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751405AbdAPNne (ORCPT ); Mon, 16 Jan 2017 08:43:34 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:40691 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751254AbdAPNnb (ORCPT ); Mon, 16 Jan 2017 08:43:31 -0500 Date: Mon, 16 Jan 2017 14:43:25 +0100 (CET) From: Thomas Gleixner To: Vikas Shivappa cc: vikas.shivappa@intel.com, linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, mingo@kernel.org, peterz@infradead.org, ravi.v.shankar@intel.com, tony.luck@intel.com, fenghua.yu@intel.com, h.peter.anvin@intel.com Subject: Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface In-Reply-To: <1484076788-25385-2-git-send-email-vikas.shivappa@linux.intel.com> Message-ID: References: <1484076788-25385-1-git-send-email-vikas.shivappa@linux.intel.com> <1484076788-25385-2-git-send-email-vikas.shivappa@linux.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 On Tue, 10 Jan 2017, Vikas Shivappa wrote: > Memory b/w allocation is part of Intel RDT(resource director technology) > which lets user control the amount of memory b/w (L2 external b/w) per > thread. This is done programming MSR interfaces like cache allocation > technology and other RDT features. > This patch adds documentation for Memory b/w allocation interface usage. Sigh. I told you how often that 'This patch' is crap. We already know that this is a patch. Read and finally act according to Documentation/process/SubmittingPatches > +Memory b/w throttle Can we please spell out Bandwidth at least once? b/w can mean anything (black/white, both ways ...) > +------------------- > +For Memory b/w resource, the portion of total memory b/w the user can > +restrict or 'throttle by' is indicated by the thrtl_by values. > + > +Throttle by values could be linear scale or non-linear scale. In linear > +scale a thrtl_by value of say 20 would throttle the memory b/w by 20% > +allowing only 80% max b/w. In nonlinear scale currently SDM specifies > +throttle values in 2^n values. However the h/w does not guarantee a > +specific curve for the amount of memory b/w that is actually throttled. > +But for any thrtl_by value x > y, its guaranteed that x would throttle > +more b/w than y. The info directory specifies the max thrtl_by value > +and thrtl_by granularity. This interface is really crap. The natural way to express it is: Requested Bandwidth = X % i.e. 100% is unthrottled. The info file should tell the minimum bandwidth,the granularity value and the scale mode. The actual programming should just take a bandwidth percentage value between 0 and 100. The written value is adjusted by the write function to the granularity and minimum bandwidth, so a subsequent readout will tell the effective value. That's important because that allows scripts to work independent of the actual hardware implementation with default bandwidth configurations and then allows the user/admin to readout the effective values on a particular machine. If someone wants to adjust them machine specific, that's possible as well. Aside of that this documentation should contain some information about the limitations of that bandwidth control, i.e. the fact that this is a core specific mechanism and using a high bandwidth and a low bandwidth setting on two threads sharing a core will throttle the high bandwidth thread inadvertently. That's really important to mention in the documentation because that's going to bring interesting surprises for users. Thanks, tglx