From: Shivappa Vikas <vikas.shivappa@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Shivappa Vikas <vikas.shivappa@intel.com>,
Vikas Shivappa <vikas.shivappa@linux.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
Date: Mon, 23 Jan 2017 10:57:26 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1701231056070.3301@vshiva-Udesk> (raw)
In-Reply-To: <alpine.DEB.2.20.1701180956330.3464@nanos>
On Wed, 18 Jan 2017, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Mon, 16 Jan 2017, Thomas Gleixner wrote:
>>> 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.
>
> The question is whether this non linear scale thing is just a first
> implementation attempt and any sane hardware in the future will use the
> percentage value (which is an approximation as well).
>
> If that non-linear scale is not going to be prevalent, then we really can
> live with the fallout of a particular CPU type.
>
> If it's going to stay, then Intel should be able to provide simple tables
> which give us the required information for a particular CPU model.
By sample table - does this mean we can map a throttle value in non-linear
scale to its percentage ?
Thanks,
Vikas
>
> Thanks,
>
> tglx
>
next prev parent reply other threads:[~2017-01-23 18:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 19:33 [PATCH 0/8 V1] x86/intel_rdt: Memory b/w Allocation support Vikas Shivappa
2017-01-10 19:33 ` [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface Vikas Shivappa
2017-01-16 13:43 ` Thomas Gleixner
2017-01-18 0:51 ` Shivappa Vikas
2017-01-18 9:01 ` Thomas Gleixner
2017-01-23 18:57 ` Shivappa Vikas [this message]
2017-01-23 19:01 ` Thomas Gleixner
2017-01-24 22:10 ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 2/8] x86/intel_rdt/mba: Generalize the naming to get ready for MBA Vikas Shivappa
2017-01-16 13:45 ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 3/8] x86/intel_rdt/mba: Improvements to handle more RDT resources like MBA Vikas Shivappa
2017-01-16 13:54 ` Thomas Gleixner
2017-01-18 0:53 ` Shivappa Vikas
2017-01-18 9:05 ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 4/8] x86/intel_rdt/mba: Memory b/w allocation feature detect Vikas Shivappa
2017-01-16 13:59 ` Thomas Gleixner
2017-01-16 14:41 ` Peter Zijlstra
2017-01-16 16:16 ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 5/8] x86/intel_rct/mba: Add MBA structures and initialize MBA Vikas Shivappa
2017-01-16 14:06 ` Thomas Gleixner
2017-01-18 0:56 ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 6/8] x86/intel_rdt/mba: Add info directory files for MBA Vikas Shivappa
2017-01-16 14:14 ` Thomas Gleixner
2017-01-18 1:02 ` Shivappa Vikas
2017-01-18 9:08 ` Thomas Gleixner
2017-01-23 19:45 ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 7/8] x86/intel_rdt/mba: Add schemata file support " Vikas Shivappa
2017-01-16 16:07 ` Thomas Gleixner
2017-01-18 1:03 ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 8/8] x86/intel_rdt: rmdir,umount and hotcpu updates " Vikas Shivappa
2017-01-16 16:13 ` Thomas Gleixner
2017-01-23 20:18 ` Shivappa Vikas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1701231056070.3301@vshiva-Udesk \
--to=vikas.shivappa@intel.com \
--cc=fenghua.yu@intel.com \
--cc=h.peter.anvin@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vikas.shivappa@linux.intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.