From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972AbdARAvj (ORCPT ); Tue, 17 Jan 2017 19:51:39 -0500 Received: from mga03.intel.com ([134.134.136.65]:12193 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751924AbdARAvX (ORCPT ); Tue, 17 Jan 2017 19:51:23 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,247,1477983600"; d="scan'208";a="923721816" Date: Tue, 17 Jan 2017 16:51:43 -0800 (PST) From: Shivappa Vikas X-X-Sender: vikas@vshiva-Udesk To: Thomas Gleixner cc: Vikas Shivappa , 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: 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.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Jan 2017, Thomas Gleixner wrote: > 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 wanted to do it this way which did seem more intuitive but the issue is with the non-linear scale which the hardware does not guarantee a particular percentage for a particular value. Or we don't know the curve for delay value vs. actual b/w throttled. ex: in non linear scale , the granularity is 2^n. Max : 512 Say a value of 256 is not guaranteed to have 50% or even follow a curve where we can calculate the corresponding percentage. > > 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. Ok , will do. Thanks, Vikas That's really important to mention in the documentation > because that's going to bring interesting surprises for users. > > Thanks, > > tglx > > > >