[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 01 Feb 2017 16:35:21 -0800
From: Andi Kleen <andi@...stfloor.org>
To: "Luck\, Tony" <tony.luck@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
David Carrillo-Cisneros <davidcc@...gle.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
"Shivappa\, Vikas" <vikas.shivappa@...el.com>,
Stephane Eranian <eranian@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, "hpa\@zytor.com" <hpa@...or.com>,
Ingo Molnar <mingo@...nel.org>,
"Peter Zijlstra" <peterz@...radead.org>,
"Shankar\, Ravi V" <ravi.v.shankar@...el.com>,
"Yu\, Fenghua" <fenghua.yu@...el.com>,
"Kleen\, Andi" <andi.kleen@...el.com>,
"Anvin\, H Peter" <h.peter.anvin@...el.com>
Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
"Luck, Tony" <tony.luck@...el.com> writes:
> 9) Measure per logical CPU (pick active RMID in same precedence for task/cpu as CAT picks CLOSID)
> 10) Put multiple CPUs into a group
I'm not sure this is a real requirement. It's just an optimization,
right? If you can assign policies to threads, you can implicitly set it
per CPU through affinity (or the other way around).
The only benefit would be possibly less context switch overhead,
but if all the thread (including idle) assigned to a CPU have the
same policy it would have the same results.
I suspect dropping this would likely simplify the interface significantly.
-Andi
Powered by blists - more mailing lists