Re: [PATCH] cacheinfo: Introduce cache id

2016-07-04 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 07:24:27PM +, Yu, Fenghua wrote:
> I haven't tested on AMD. But I think AMD should have the same code.

Again, bear in mind, this is a qemu+kvm guest.

> Could you please check if
> /sys/device/system/cpu/cpu#/cache/index#/shared_cpu_map contains only
> the cpu itself?

Yes it does:

$ grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map
/sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu4/cache/index0/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index1/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index2/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu5/cache/index0/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index1/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index2/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu6/cache/index0/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu6/cache/index1/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu6/cache/index2/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu7/cache/index0/shared_cpu_map:1:80
/sys/devices/system/cpu/cpu7/cache/index1/shared_cpu_map:1:80
/sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map:1:80

Here's the same from a real AMD system:

 grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map
/sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu4/cache/index0/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index1/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index2/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu5/cache/index0/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index1/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index2/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index3/shared_cpu_map:1:3f

L3 is correctly shared between all cores.

> From the cache id you dump on KVM, it tells there are 8 cache leaf 0,
> 8 cache leaf 1, and 8 cache leaf 2. That means each CPU has its own
> 3 caches (I can't tell from the cache id which level they are. The
> cache/index#/level will tell that).
>
> If this is not the case, maybe cache id doesn't work on AMD. Maybe I
> don't enable cache id for AMD?

Nah, leave it as it is. Who knows what we might use it for on AMD.

> From the info, cache id on one level is unique on that level across the board.

Same on the AMD box:

$ grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/id
/sys/devices/system/cpu/cpu0/cache/index0/id:1:0
/sys/devices/system/cpu/cpu0/cache/index1/id:1:0
/sys/devices/system/cpu/cpu0/cache/index2/id:1:0
/sys/devices/system/cpu/cpu0/cache/index3/id:1:0
/sys/devices/system/cpu/cpu1/cache/index0/id:1:1
/sys/devices/system/cpu/cpu1/cache/index1/id:1:1
/sys/devices/system/cpu/cpu1/cache/index2/id:1:1
/sys/devices/system/cpu/cpu1/cache/index3/id:1:1
/sys/devices/system/cpu/cpu2/cache/index0/id:1:2
/sys/devices/system/cpu/cpu2/cache/index1/id:1:2
/sys/devices/system/cpu/cpu2/cache/index2/id:1:2
/sys/devices/system/cpu/cpu2/cache/index3/id:1:2
/sys/devices/system/cpu/cpu3/cache/index0/id:1:3
/sys/devices/system/cpu/cpu3/cache/index1/id:1:3
/sys/devices/system/cpu/cpu3/cache/index2/id:1:3
/sys/devices/system/cpu/cpu3/cache/index3/id:1:3
/sys/devices/system/cpu/cpu4/cache/index0/id:1:4
/sys/devices/system/cpu/cpu4/cache/index1/id:1:4

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-04 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 07:24:27PM +, Yu, Fenghua wrote:
> I haven't tested on AMD. But I think AMD should have the same code.

Again, bear in mind, this is a qemu+kvm guest.

> Could you please check if
> /sys/device/system/cpu/cpu#/cache/index#/shared_cpu_map contains only
> the cpu itself?

Yes it does:

$ grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map
/sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu4/cache/index0/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index1/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index2/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu5/cache/index0/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index1/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index2/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu6/cache/index0/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu6/cache/index1/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu6/cache/index2/shared_cpu_map:1:40
/sys/devices/system/cpu/cpu7/cache/index0/shared_cpu_map:1:80
/sys/devices/system/cpu/cpu7/cache/index1/shared_cpu_map:1:80
/sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map:1:80

Here's the same from a real AMD system:

 grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_map
/sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:1:01
/sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:1:02
/sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu2/cache/index0/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index1/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_map:1:04
/sys/devices/system/cpu/cpu2/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu3/cache/index0/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map:1:08
/sys/devices/system/cpu/cpu3/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu4/cache/index0/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index1/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index2/shared_cpu_map:1:10
/sys/devices/system/cpu/cpu4/cache/index3/shared_cpu_map:1:3f
/sys/devices/system/cpu/cpu5/cache/index0/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index1/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index2/shared_cpu_map:1:20
/sys/devices/system/cpu/cpu5/cache/index3/shared_cpu_map:1:3f

L3 is correctly shared between all cores.

> From the cache id you dump on KVM, it tells there are 8 cache leaf 0,
> 8 cache leaf 1, and 8 cache leaf 2. That means each CPU has its own
> 3 caches (I can't tell from the cache id which level they are. The
> cache/index#/level will tell that).
>
> If this is not the case, maybe cache id doesn't work on AMD. Maybe I
> don't enable cache id for AMD?

Nah, leave it as it is. Who knows what we might use it for on AMD.

> From the info, cache id on one level is unique on that level across the board.

Same on the AMD box:

$ grep . -EriIn /sys/devices/system/cpu/cpu*/cache/index*/id
/sys/devices/system/cpu/cpu0/cache/index0/id:1:0
/sys/devices/system/cpu/cpu0/cache/index1/id:1:0
/sys/devices/system/cpu/cpu0/cache/index2/id:1:0
/sys/devices/system/cpu/cpu0/cache/index3/id:1:0
/sys/devices/system/cpu/cpu1/cache/index0/id:1:1
/sys/devices/system/cpu/cpu1/cache/index1/id:1:1
/sys/devices/system/cpu/cpu1/cache/index2/id:1:1
/sys/devices/system/cpu/cpu1/cache/index3/id:1:1
/sys/devices/system/cpu/cpu2/cache/index0/id:1:2
/sys/devices/system/cpu/cpu2/cache/index1/id:1:2
/sys/devices/system/cpu/cpu2/cache/index2/id:1:2
/sys/devices/system/cpu/cpu2/cache/index3/id:1:2
/sys/devices/system/cpu/cpu3/cache/index0/id:1:3
/sys/devices/system/cpu/cpu3/cache/index1/id:1:3
/sys/devices/system/cpu/cpu3/cache/index2/id:1:3
/sys/devices/system/cpu/cpu3/cache/index3/id:1:3
/sys/devices/system/cpu/cpu4/cache/index0/id:1:4
/sys/devices/system/cpu/cpu4/cache/index1/id:1:4

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-04 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 07:08:56PM +, Yu, Fenghua wrote:
> For L3 schema on a two socket system which has two L3 caches, user input:
> L3:0=3;1=f

Ok, so you basically want to read out the cache id from sysfs so that
userspace can configure CAT properly. Thanks for the detailed writeup.

Btw, some of that text should be added to

Documentation/ABI/testing/sysfs-devices-system-cpu

explaining the new 'id' node.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-04 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 07:08:56PM +, Yu, Fenghua wrote:
> For L3 schema on a two socket system which has two L3 caches, user input:
> L3:0=3;1=f

Ok, so you basically want to read out the cache id from sysfs so that
userspace can configure CAT properly. Thanks for the detailed writeup.

Btw, some of that text should be added to

Documentation/ABI/testing/sysfs-devices-system-cpu

explaining the new 'id' node.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 

> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:36 AM
> To: Yu, Fenghua <fenghua...@intel.com>
> Cc: Luck, Tony <tony.l...@intel.com>; Thomas Gleixner
> <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter
> <h.peter.an...@intel.com>; Peter Zijlstra <pet...@infradead.org>;
> Stephane Eranian <eran...@google.com>; Shankar, Ravi V
> <ravi.v.shan...@intel.com>; Vikas Shivappa
> <vikas.shiva...@linux.intel.com>; linux-kernel  ker...@vger.kernel.org>; x86 <x...@kernel.org>
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 06:01:06PM +, Yu, Fenghua wrote:
> > Cache id is unique on the same level of cache across platform.
> 
> Btw, I forgot to ask in the reply to Tony: how are those cache IDs exactly
> going to be used? An example please...
> 
> > Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.
> 
> Bah, my kvm is on an AMD guest - forget what it says :-)

I haven't tested on AMD. But I think AMD should have the same code.

Could you please check if 
/sys/device/system/cpu/cpu#/cache/index#/shared_cpu_map contains only the cpu 
itself? From the cache id you dump on KVM, it tells there are 8 cache leaf 0, 8 
cache leaf 1, and 8 cache leaf 2. That means each CPU has its own 3 caches (I 
can't tell from the cache id which level they are. The cache/index#/level will 
tell that).

If this is not the case, maybe cache id doesn't work on AMD. Maybe I don't 
enable cache id for AMD?

> 
> > Cache id is unique on the same level across platform.
> >
> > #find /sys/device/system/cpu/. -name id|xargs cat
> 
> Btw, you could do
> 
> grep . /sys/devices/system/cpu/cpu*/cache/index*/id
> 
> and it'll give you the absolute filepaths too, so that the output is parseable
> easier.

Thanks for the command. Here is more nicer info:)

From the info, cache id on one level is unique on that level across the board.

/sys/devices/system/cpu/cpu0/cache/index0/id:0
/sys/devices/system/cpu/cpu0/cache/index1/id:0
/sys/devices/system/cpu/cpu0/cache/index2/id:0
/sys/devices/system/cpu/cpu0/cache/index3/id:0
/sys/devices/system/cpu/cpu10/cache/index0/id:17
/sys/devices/system/cpu/cpu10/cache/index1/id:17
/sys/devices/system/cpu/cpu10/cache/index2/id:17
/sys/devices/system/cpu/cpu10/cache/index3/id:0
/sys/devices/system/cpu/cpu11/cache/index0/id:18
/sys/devices/system/cpu/cpu11/cache/index1/id:18
/sys/devices/system/cpu/cpu11/cache/index2/id:18
/sys/devices/system/cpu/cpu11/cache/index3/id:0
/sys/devices/system/cpu/cpu12/cache/index0/id:19
/sys/devices/system/cpu/cpu12/cache/index1/id:19
/sys/devices/system/cpu/cpu12/cache/index2/id:19
/sys/devices/system/cpu/cpu12/cache/index3/id:0
/sys/devices/system/cpu/cpu13/cache/index0/id:20
/sys/devices/system/cpu/cpu13/cache/index1/id:20
/sys/devices/system/cpu/cpu13/cache/index2/id:20
/sys/devices/system/cpu/cpu13/cache/index3/id:0
/sys/devices/system/cpu/cpu14/cache/index0/id:24
/sys/devices/system/cpu/cpu14/cache/index1/id:24
/sys/devices/system/cpu/cpu14/cache/index2/id:24
/sys/devices/system/cpu/cpu14/cache/index3/id:0
/sys/devices/system/cpu/cpu15/cache/index0/id:25
/sys/devices/system/cpu/cpu15/cache/index1/id:25
/sys/devices/system/cpu/cpu15/cache/index2/id:25
/sys/devices/system/cpu/cpu15/cache/index3/id:0
/sys/devices/system/cpu/cpu16/cache/index0/id:26
/sys/devices/system/cpu/cpu16/cache/index1/id:26
/sys/devices/system/cpu/cpu16/cache/index2/id:26
/sys/devices/system/cpu/cpu16/cache/index3/id:0
/sys/devices/system/cpu/cpu17/cache/index0/id:27
/sys/devices/system/cpu/cpu17/cache/index1/id:27
/sys/devices/system/cpu/cpu17/cache/index2/id:27
/sys/devices/system/cpu/cpu17/cache/index3/id:0
/sys/devices/system/cpu/cpu18/cache/index0/id:32
/sys/devices/system/cpu/cpu18/cache/index1/id:32
/sys/devices/system/cpu/cpu18/cache/index2/id:32
/sys/devices/system/cpu/cpu18/cache/index3/id:1
/sys/devices/system/cpu/cpu19/cache/index0/id:33
/sys/devices/system/cpu/cpu19/cache/index1/id:33
/sys/devices/system/cpu/cpu19/cache/index2/id:33
/sys/devices/system/cpu/cpu19/cache/index3/id:1
/sys/devices/system/cpu/cpu1/cache/index0/id:1
/sys/devices/system/cpu/cpu1/cache/index1/id:1
/sys/devices/system/cpu/cpu1/cache/index2/id:1
/sys/devices/system/cpu/cpu1/cache/index3/id:0
/sys/devices/system/cpu/cpu20/cache/index0/id:34
/sys/devices/system/cpu/cpu20/cache/index1/id:34
/sys/devices/system/cpu/cpu20/cache/index2/id:34
/sys/devices/system/cpu/cpu20/cache/index3/id:1
/sys/devices/system/cpu/cpu21/cache/index0/id:35
/sys/devices/system/cpu/cpu21/cache/index1/id:35
/sys/devices/system/cpu/cpu21/cache/index2/id:35
/sys/devices/system/cpu/cpu21/cache/index3/id:1
/sys/devices/system/cpu/cpu22/cache/index0/id:36
/sys/devices/system/cpu/cpu22/cache/index1/id:36
/sys/devices/system/cpu/cpu22/cache/index2/id:36
/sys/devices/system/cpu/cpu22/cache/index3/

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 

> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:36 AM
> To: Yu, Fenghua 
> Cc: Luck, Tony ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel  ker...@vger.kernel.org>; x86 
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 06:01:06PM +, Yu, Fenghua wrote:
> > Cache id is unique on the same level of cache across platform.
> 
> Btw, I forgot to ask in the reply to Tony: how are those cache IDs exactly
> going to be used? An example please...
> 
> > Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.
> 
> Bah, my kvm is on an AMD guest - forget what it says :-)

I haven't tested on AMD. But I think AMD should have the same code.

Could you please check if 
/sys/device/system/cpu/cpu#/cache/index#/shared_cpu_map contains only the cpu 
itself? From the cache id you dump on KVM, it tells there are 8 cache leaf 0, 8 
cache leaf 1, and 8 cache leaf 2. That means each CPU has its own 3 caches (I 
can't tell from the cache id which level they are. The cache/index#/level will 
tell that).

If this is not the case, maybe cache id doesn't work on AMD. Maybe I don't 
enable cache id for AMD?

> 
> > Cache id is unique on the same level across platform.
> >
> > #find /sys/device/system/cpu/. -name id|xargs cat
> 
> Btw, you could do
> 
> grep . /sys/devices/system/cpu/cpu*/cache/index*/id
> 
> and it'll give you the absolute filepaths too, so that the output is parseable
> easier.

Thanks for the command. Here is more nicer info:)

From the info, cache id on one level is unique on that level across the board.

/sys/devices/system/cpu/cpu0/cache/index0/id:0
/sys/devices/system/cpu/cpu0/cache/index1/id:0
/sys/devices/system/cpu/cpu0/cache/index2/id:0
/sys/devices/system/cpu/cpu0/cache/index3/id:0
/sys/devices/system/cpu/cpu10/cache/index0/id:17
/sys/devices/system/cpu/cpu10/cache/index1/id:17
/sys/devices/system/cpu/cpu10/cache/index2/id:17
/sys/devices/system/cpu/cpu10/cache/index3/id:0
/sys/devices/system/cpu/cpu11/cache/index0/id:18
/sys/devices/system/cpu/cpu11/cache/index1/id:18
/sys/devices/system/cpu/cpu11/cache/index2/id:18
/sys/devices/system/cpu/cpu11/cache/index3/id:0
/sys/devices/system/cpu/cpu12/cache/index0/id:19
/sys/devices/system/cpu/cpu12/cache/index1/id:19
/sys/devices/system/cpu/cpu12/cache/index2/id:19
/sys/devices/system/cpu/cpu12/cache/index3/id:0
/sys/devices/system/cpu/cpu13/cache/index0/id:20
/sys/devices/system/cpu/cpu13/cache/index1/id:20
/sys/devices/system/cpu/cpu13/cache/index2/id:20
/sys/devices/system/cpu/cpu13/cache/index3/id:0
/sys/devices/system/cpu/cpu14/cache/index0/id:24
/sys/devices/system/cpu/cpu14/cache/index1/id:24
/sys/devices/system/cpu/cpu14/cache/index2/id:24
/sys/devices/system/cpu/cpu14/cache/index3/id:0
/sys/devices/system/cpu/cpu15/cache/index0/id:25
/sys/devices/system/cpu/cpu15/cache/index1/id:25
/sys/devices/system/cpu/cpu15/cache/index2/id:25
/sys/devices/system/cpu/cpu15/cache/index3/id:0
/sys/devices/system/cpu/cpu16/cache/index0/id:26
/sys/devices/system/cpu/cpu16/cache/index1/id:26
/sys/devices/system/cpu/cpu16/cache/index2/id:26
/sys/devices/system/cpu/cpu16/cache/index3/id:0
/sys/devices/system/cpu/cpu17/cache/index0/id:27
/sys/devices/system/cpu/cpu17/cache/index1/id:27
/sys/devices/system/cpu/cpu17/cache/index2/id:27
/sys/devices/system/cpu/cpu17/cache/index3/id:0
/sys/devices/system/cpu/cpu18/cache/index0/id:32
/sys/devices/system/cpu/cpu18/cache/index1/id:32
/sys/devices/system/cpu/cpu18/cache/index2/id:32
/sys/devices/system/cpu/cpu18/cache/index3/id:1
/sys/devices/system/cpu/cpu19/cache/index0/id:33
/sys/devices/system/cpu/cpu19/cache/index1/id:33
/sys/devices/system/cpu/cpu19/cache/index2/id:33
/sys/devices/system/cpu/cpu19/cache/index3/id:1
/sys/devices/system/cpu/cpu1/cache/index0/id:1
/sys/devices/system/cpu/cpu1/cache/index1/id:1
/sys/devices/system/cpu/cpu1/cache/index2/id:1
/sys/devices/system/cpu/cpu1/cache/index3/id:0
/sys/devices/system/cpu/cpu20/cache/index0/id:34
/sys/devices/system/cpu/cpu20/cache/index1/id:34
/sys/devices/system/cpu/cpu20/cache/index2/id:34
/sys/devices/system/cpu/cpu20/cache/index3/id:1
/sys/devices/system/cpu/cpu21/cache/index0/id:35
/sys/devices/system/cpu/cpu21/cache/index1/id:35
/sys/devices/system/cpu/cpu21/cache/index2/id:35
/sys/devices/system/cpu/cpu21/cache/index3/id:1
/sys/devices/system/cpu/cpu22/cache/index0/id:36
/sys/devices/system/cpu/cpu22/cache/index1/id:36
/sys/devices/system/cpu/cpu22/cache/index2/id:36
/sys/devices/system/cpu/cpu22/cache/index3/id:1
/sys/devices/system/cpu/cpu23/cache/index0/id:40
/sys/devices/system/cpu/cpu23/cache/index1/id:40
/sys/devices/system/cpu/cpu23/cache/index2/id:40
/sys/devices/system/cpu/cpu23/cache/index3/id:1
/sys/devices/system/cpu/cpu24/cache/index0/id:41
/sys/devices/system/cpu/cpu24/ca

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:40 AM
> On Fri, Jul 01, 2016 at 06:32:19PM +, Yu, Fenghua wrote:
> > We has prefix "L3" or "L2" in the syntax, id is for that level in each 
> > line.b
> 
> Give me a full example, please, how the id is going to be used.

Intel Cache Allocation Technology allows app to use only portion of L2 or L3 
cache. Each cache has its own allocation MSR registers array which contains CBM 
(Cache Bit Mask) to specify which part of cache is allocated.

We have a user interface to allow user to input CBM bits to a specific cache 
MSR register array. In current kernel, there is no identification of the cache. 
So we propose the cache id to identify the cache.

So CAT user interface is called schemas which have multiple lines. Each line 
describes one cache allocation CBM (or schema).

For L3 schema on a two socket system which has two L3 caches, user input:
L3:0=3;1=f
That means user wants to allocate CBM 3 on L3 id 0 and CBM f on L3 id 1. Kernel 
gets this info and writes CBM 3 to one MSR register on the L3 cache with cache 
id 0 and write CBM f to one MSR register on another L3 cache with cache id 1.

User can allow a task to use this schema. When the task is running on a CPU 
that shares the L3 cache of cache id 0, the CBM 3 is used (via another PQR_MSR 
register pointing to the CBM) and a portion of the L3 of cache id 0 is 
allocated to the task and task can only uses that portion. When the task is 
scheduled on a CPU that shares the L3 cache of cache id 1, the CBM f is used 
and a portion of the L3 of cache id 1 is allocated to the task for use.

The current kernel has store cache info in cacheinfo structure and each 
cacheinfo eventually is exported in /sys/device/system/cpu/cpu#/cache/index#/. 
BUTthere is no existing identification methodology to allow user to specify 
a cache. CAT wants to allow user to use one id to specify which cache. That's 
the reason we propose the cache id in the patch.

Please note, socket# and core# and combination of them can not be used to 
identify a cache architecturally. A lot of machines have L3 per socket and L2 
per core. BUT architecturally one socket can have more than one L3 and L2 can 
be shared by more than one core.

Thanks.

-Fenghua

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:40 AM
> On Fri, Jul 01, 2016 at 06:32:19PM +, Yu, Fenghua wrote:
> > We has prefix "L3" or "L2" in the syntax, id is for that level in each 
> > line.b
> 
> Give me a full example, please, how the id is going to be used.

Intel Cache Allocation Technology allows app to use only portion of L2 or L3 
cache. Each cache has its own allocation MSR registers array which contains CBM 
(Cache Bit Mask) to specify which part of cache is allocated.

We have a user interface to allow user to input CBM bits to a specific cache 
MSR register array. In current kernel, there is no identification of the cache. 
So we propose the cache id to identify the cache.

So CAT user interface is called schemas which have multiple lines. Each line 
describes one cache allocation CBM (or schema).

For L3 schema on a two socket system which has two L3 caches, user input:
L3:0=3;1=f
That means user wants to allocate CBM 3 on L3 id 0 and CBM f on L3 id 1. Kernel 
gets this info and writes CBM 3 to one MSR register on the L3 cache with cache 
id 0 and write CBM f to one MSR register on another L3 cache with cache id 1.

User can allow a task to use this schema. When the task is running on a CPU 
that shares the L3 cache of cache id 0, the CBM 3 is used (via another PQR_MSR 
register pointing to the CBM) and a portion of the L3 of cache id 0 is 
allocated to the task and task can only uses that portion. When the task is 
scheduled on a CPU that shares the L3 cache of cache id 1, the CBM f is used 
and a portion of the L3 of cache id 1 is allocated to the task for use.

The current kernel has store cache info in cacheinfo structure and each 
cacheinfo eventually is exported in /sys/device/system/cpu/cpu#/cache/index#/. 
BUTthere is no existing identification methodology to allow user to specify 
a cache. CAT wants to allow user to use one id to specify which cache. That's 
the reason we propose the cache id in the patch.

Please note, socket# and core# and combination of them can not be used to 
identify a cache architecturally. A lot of machines have L3 per socket and L2 
per core. BUT architecturally one socket can have more than one L3 and L2 can 
be shared by more than one core.

Thanks.

-Fenghua

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 11:00:35AM -0700, Luck, Tony wrote:
> For CAT we only need the IDs to be unique at each level. Our tentative
> syntax for the schema file for CAT looks like this (for a theoretical
> system supporting CAT in both L2 and L3 with two L3 caches and eight L2 
> caches)
> 
> L3:id0=fff;id1=ff0
> L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0

So wouldn't it be straightforward and natural to do the following
nomenclature (which basically suggests itself):

ID.

?

So that the ID hierarchy above is:

ID3.0 ID3.1
ID2.0 ID2.1 ID2.2 ID2.3 ... ID2.7

I don't know if that's useful though.

I mean, we have that info in the path anyway:

/sys/devices/system/cpu/cpu0/cache/index3/id = 0xfff
...

and so on.

Whatever you do, as long as the nomenclature is documented somewhere,
say Documentation/x86/topology.txt, for example, we should be fine.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 11:00:35AM -0700, Luck, Tony wrote:
> For CAT we only need the IDs to be unique at each level. Our tentative
> syntax for the schema file for CAT looks like this (for a theoretical
> system supporting CAT in both L2 and L3 with two L3 caches and eight L2 
> caches)
> 
> L3:id0=fff;id1=ff0
> L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0

So wouldn't it be straightforward and natural to do the following
nomenclature (which basically suggests itself):

ID.

?

So that the ID hierarchy above is:

ID3.0 ID3.1
ID2.0 ID2.1 ID2.2 ID2.3 ... ID2.7

I don't know if that's useful though.

I mean, we have that info in the path anyway:

/sys/devices/system/cpu/cpu0/cache/index3/id = 0xfff
...

and so on.

Whatever you do, as long as the nomenclature is documented somewhere,
say Documentation/x86/topology.txt, for example, we should be fine.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 06:32:19PM +, Yu, Fenghua wrote:
> We has prefix "L3" or "L2" in the syntax, id is for that level in each line.b

Give me a full example, please, how the id is going to be used.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 06:32:19PM +, Yu, Fenghua wrote:
> We has prefix "L3" or "L2" in the syntax, id is for that level in each line.b

Give me a full example, please, how the id is going to be used.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 06:01:06PM +, Yu, Fenghua wrote:
> Cache id is unique on the same level of cache across platform.

Btw, I forgot to ask in the reply to Tony: how are those cache IDs
exactly going to be used? An example please...

> Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.

Bah, my kvm is on an AMD guest - forget what it says :-)

> Cache id is unique on the same level across platform.
> 
> #find /sys/device/system/cpu/. -name id|xargs cat

Btw, you could do

grep . /sys/devices/system/cpu/cpu*/cache/index*/id

and it'll give you the absolute filepaths too, so that the output is
parseable easier.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 06:01:06PM +, Yu, Fenghua wrote:
> Cache id is unique on the same level of cache across platform.

Btw, I forgot to ask in the reply to Tony: how are those cache IDs
exactly going to be used? An example please...

> Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.

Bah, my kvm is on an AMD guest - forget what it says :-)

> Cache id is unique on the same level across platform.
> 
> #find /sys/device/system/cpu/. -name id|xargs cat

Btw, you could do

grep . /sys/devices/system/cpu/cpu*/cache/index*/id

and it'll give you the absolute filepaths too, so that the output is
parseable easier.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:29 AM
> To: Luck, Tony <tony.l...@intel.com>
> Cc: Yu, Fenghua <fenghua...@intel.com>; Thomas Gleixner
> <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter
> <h.peter.an...@intel.com>; Peter Zijlstra <pet...@infradead.org>;
> Stephane Eranian <eran...@google.com>; Shankar, Ravi V
> <ravi.v.shan...@intel.com>; Vikas Shivappa
> <vikas.shiva...@linux.intel.com>; linux-kernel  ker...@vger.kernel.org>; x86 <x...@kernel.org>
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 11:00:35AM -0700, Luck, Tony wrote:
> > For CAT we only need the IDs to be unique at each level. Our tentative
> > syntax for the schema file for CAT looks like this (for a theoretical
> > system supporting CAT in both L2 and L3 with two L3 caches and eight
> > L2 caches)
> >
> > L3:id0=fff;id1=ff0
> > L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0
> 
> So wouldn't it be straightforward and natural to do the following
> nomenclature (which basically suggests itself):
> 
> ID.

We has prefix "L3" or "L2" in the syntax, id is for that level in each line.b

> 
> ?
> 
> So that the ID hierarchy above is:
> 
> ID3.0 ID3.1
> ID2.0 ID2.1 ID2.2 ID2.3 ... ID2.7
> 
> I don't know if that's useful though.
> 
> I mean, we have that info in the path anyway:
> 
> /sys/devices/system/cpu/cpu0/cache/index3/id = 0xfff ...
> 
> and so on.
> 
> Whatever you do, as long as the nomenclature is documented somewhere,
> say Documentation/x86/topology.txt, for example, we should be fine.
> 
> --
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> --

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 11:29 AM
> To: Luck, Tony 
> Cc: Yu, Fenghua ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel  ker...@vger.kernel.org>; x86 
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 11:00:35AM -0700, Luck, Tony wrote:
> > For CAT we only need the IDs to be unique at each level. Our tentative
> > syntax for the schema file for CAT looks like this (for a theoretical
> > system supporting CAT in both L2 and L3 with two L3 caches and eight
> > L2 caches)
> >
> > L3:id0=fff;id1=ff0
> > L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0
> 
> So wouldn't it be straightforward and natural to do the following
> nomenclature (which basically suggests itself):
> 
> ID.

We has prefix "L3" or "L2" in the syntax, id is for that level in each line.b

> 
> ?
> 
> So that the ID hierarchy above is:
> 
> ID3.0 ID3.1
> ID2.0 ID2.1 ID2.2 ID2.3 ... ID2.7
> 
> I don't know if that's useful though.
> 
> I mean, we have that info in the path anyway:
> 
> /sys/devices/system/cpu/cpu0/cache/index3/id = 0xfff ...
> 
> and so on.
> 
> Whatever you do, as long as the nomenclature is documented somewhere,
> say Documentation/x86/topology.txt, for example, we should be fine.
> 
> --
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> --

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 10:28 AM
> To: Luck, Tony <tony.l...@intel.com>
> Cc: Yu, Fenghua <fenghua...@intel.com>; Thomas Gleixner
> <t...@linutronix.de>; Ingo Molnar <mi...@elte.hu>; Anvin, H Peter
> <h.peter.an...@intel.com>; Peter Zijlstra <pet...@infradead.org>;
> Stephane Eranian <eran...@google.com>; Shankar, Ravi V
> <ravi.v.shan...@intel.com>; Vikas Shivappa
> <vikas.shiva...@linux.intel.com>; linux-kernel  ker...@vger.kernel.org>; x86 <x...@kernel.org>
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote:
> > Here's the situation.  We have lots of (mostly) independent caches on a
> system.
> > The L3 cache (also called LLC - Last Level Cache - in some
> > documentation) is usually shared by all cpus on a physical socket. The
> > L1 and L2 caches are typically local to a core, so only shared by the
> hyperthreads on a core.
> > But I say "usually" and "typically" because the architecture doesn't
> > require that. We could have multiple separate L3 caches on a socket
> > with a subset of cpus assigned to each of them. We could have an L2
> > cache that is shared by two or more cores.
> 
> Right, so I'm presuming we don't want to make it special to the LLC but be
> generic and have any cache level have an ID.
> 
> And, since we simply call it cache, how about we drop the "node" thing and
> simply talk about cache and it having an ID. We say it is unique on the system
> and the cache with ID X is local to only thread X and the cache with ID Y is
> shared by threads Y_0, ... Y_k. And so on...
> 
> How does that sound?

That's good for me.

> 
> Struct doc will have then:
> 
>  /**
>   * struct cacheinfo - represent a cache leaf node
> + * @id: This cache's ID. ID is unique on the platform.
> 
> ?
> 
> which begs the question, does get_cache_id() give unique IDs for all caches
> in the hierarchy on the system?

Cache id is unique on the same level of cache across platform.

> 
> Because I tried this patch quickly in kvm and it was of course wrong but it
> hints at that important question:
> 
> cpu0/cache/index0/id:0b
> cpu0/cache/index1/id:0
> cpu0/cache/index2/id:0
> cpu1/cache/index0/id:1
> cpu1/cache/index1/id:1
> cpu1/cache/index2/id:1
> cpu2/cache/index0/id:2
> cpu2/cache/index1/id:2
> cpu2/cache/index2/id:2
> cpu3/cache/index0/id:3
> cpu3/cache/index1/id:3
> cpu3/cache/index2/id:3
> cpu4/cache/index0/id:4
> cpu4/cache/index1/id:4
> cpu4/cache/index2/id:4
> cpu5/cache/index0/id:5
> cpu5/cache/index1/id:5
> cpu5/cache/index2/id:5
> cpu6/cache/index0/id:6
> cpu6/cache/index1/id:6
> cpu6/cache/index2/id:6
> cpu7/cache/index0/id:7
> cpu7/cache/index1/id:7
> cpu7/cache/index2/id:7
> 
> Basically all cache indices carry the APIC ID of the core, so L1D on
> CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same ID.

The cache id should represent shared cpus on one cache level according to SDM.

Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.
According to the cache id, there is NO shared cpu on each level. The 
shared_cpu_map
In your KVM should tell that as well, I think. I would guess all shared_cpu_map 
in each cache level on each cpu has itself on your KVM.

> 
> How does that look on a CAT system? Do all the different cache levels get
> different IDs?

On my Broadwell EP, the cache id info is as follows:

From index3/id, there are 2 cache ids for L3.
L3 cache id 0 has shared_cpu_map: 00,0030,0003
L3 cache id 1 has shared_cpu_map: ff,ffcf,fffc
Similar for L2 and L1.

Cache id is unique on the same level across platform.

#find /sys/device/system/cpu/. -name id|xargs cat
0
0
0
0
1
1
1
0
2
2
2
0
3
3
3
0
4
4
4
0
8
8
8
0
9
9
9
0
10
10
10
0
11
11
11
0
16
16
16
0
17
17
17
0
18
18
18
0
19
19
19
0
20
20
20
0
24
24
24
0
25
25
25
0
26
26
26
0
27
27
27
0
32
32
32
1
33
33
33
1
34
34
34
1
35
35
35
1
36
36
36
1
40
40
40
1
41
41
41
1
42
42
42
1
43
43
43
1
48
48
48
1
49
49
49
1
50
50
50
1
51
51
51
1
52
52
52
1
56
56
56
1
57
57
57
1
58
58
58
1
59
59
59
1
0
0
0
0
1
1
1
0
2
2
2
0
3
3
3
0
4
4
4
0
8
8
8
0
9
9
9
0
10
10
10
0
11
11
11
0
16
16
16
0
17
17
17
0
18
18
18
0
19
19
19
0
20
20
20
0
24
24
24
0
25
25
25
0
26
26
26
0
27
27
27
0
32
32
32
1
33
33
33
1
34
34
34
1
35
35
35
1
36
36
36
1
40
40
40
1
41
41
41
1
42
42
42
1
43
43
43
1
48
48
48
1
49
49
49
1
50
50
50
1
51
51
51
1
52
52
52
1
56
56
56
1
57
57
57
1
58
58
58
1
59
59
59
1

RE: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Yu, Fenghua 
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Friday, July 01, 2016 10:28 AM
> To: Luck, Tony 
> Cc: Yu, Fenghua ; Thomas Gleixner
> ; Ingo Molnar ; Anvin, H Peter
> ; Peter Zijlstra ;
> Stephane Eranian ; Shankar, Ravi V
> ; Vikas Shivappa
> ; linux-kernel  ker...@vger.kernel.org>; x86 
> Subject: Re: [PATCH] cacheinfo: Introduce cache id
> 
> On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote:
> > Here's the situation.  We have lots of (mostly) independent caches on a
> system.
> > The L3 cache (also called LLC - Last Level Cache - in some
> > documentation) is usually shared by all cpus on a physical socket. The
> > L1 and L2 caches are typically local to a core, so only shared by the
> hyperthreads on a core.
> > But I say "usually" and "typically" because the architecture doesn't
> > require that. We could have multiple separate L3 caches on a socket
> > with a subset of cpus assigned to each of them. We could have an L2
> > cache that is shared by two or more cores.
> 
> Right, so I'm presuming we don't want to make it special to the LLC but be
> generic and have any cache level have an ID.
> 
> And, since we simply call it cache, how about we drop the "node" thing and
> simply talk about cache and it having an ID. We say it is unique on the system
> and the cache with ID X is local to only thread X and the cache with ID Y is
> shared by threads Y_0, ... Y_k. And so on...
> 
> How does that sound?

That's good for me.

> 
> Struct doc will have then:
> 
>  /**
>   * struct cacheinfo - represent a cache leaf node
> + * @id: This cache's ID. ID is unique on the platform.
> 
> ?
> 
> which begs the question, does get_cache_id() give unique IDs for all caches
> in the hierarchy on the system?

Cache id is unique on the same level of cache across platform.

> 
> Because I tried this patch quickly in kvm and it was of course wrong but it
> hints at that important question:
> 
> cpu0/cache/index0/id:0b
> cpu0/cache/index1/id:0
> cpu0/cache/index2/id:0
> cpu1/cache/index0/id:1
> cpu1/cache/index1/id:1
> cpu1/cache/index2/id:1
> cpu2/cache/index0/id:2
> cpu2/cache/index1/id:2
> cpu2/cache/index2/id:2
> cpu3/cache/index0/id:3
> cpu3/cache/index1/id:3
> cpu3/cache/index2/id:3
> cpu4/cache/index0/id:4
> cpu4/cache/index1/id:4
> cpu4/cache/index2/id:4
> cpu5/cache/index0/id:5
> cpu5/cache/index1/id:5
> cpu5/cache/index2/id:5
> cpu6/cache/index0/id:6
> cpu6/cache/index1/id:6
> cpu6/cache/index2/id:6
> cpu7/cache/index0/id:7
> cpu7/cache/index1/id:7
> cpu7/cache/index2/id:7
> 
> Basically all cache indices carry the APIC ID of the core, so L1D on
> CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same ID.

The cache id should represent shared cpus on one cache level according to SDM.

Could you check cpu#/cache/index#/shared_cpu_map or shared_cpu_list.
According to the cache id, there is NO shared cpu on each level. The 
shared_cpu_map
In your KVM should tell that as well, I think. I would guess all shared_cpu_map 
in each cache level on each cpu has itself on your KVM.

> 
> How does that look on a CAT system? Do all the different cache levels get
> different IDs?

On my Broadwell EP, the cache id info is as follows:

From index3/id, there are 2 cache ids for L3.
L3 cache id 0 has shared_cpu_map: 00,0030,0003
L3 cache id 1 has shared_cpu_map: ff,ffcf,fffc
Similar for L2 and L1.

Cache id is unique on the same level across platform.

#find /sys/device/system/cpu/. -name id|xargs cat
0
0
0
0
1
1
1
0
2
2
2
0
3
3
3
0
4
4
4
0
8
8
8
0
9
9
9
0
10
10
10
0
11
11
11
0
16
16
16
0
17
17
17
0
18
18
18
0
19
19
19
0
20
20
20
0
24
24
24
0
25
25
25
0
26
26
26
0
27
27
27
0
32
32
32
1
33
33
33
1
34
34
34
1
35
35
35
1
36
36
36
1
40
40
40
1
41
41
41
1
42
42
42
1
43
43
43
1
48
48
48
1
49
49
49
1
50
50
50
1
51
51
51
1
52
52
52
1
56
56
56
1
57
57
57
1
58
58
58
1
59
59
59
1
0
0
0
0
1
1
1
0
2
2
2
0
3
3
3
0
4
4
4
0
8
8
8
0
9
9
9
0
10
10
10
0
11
11
11
0
16
16
16
0
17
17
17
0
18
18
18
0
19
19
19
0
20
20
20
0
24
24
24
0
25
25
25
0
26
26
26
0
27
27
27
0
32
32
32
1
33
33
33
1
34
34
34
1
35
35
35
1
36
36
36
1
40
40
40
1
41
41
41
1
42
42
42
1
43
43
43
1
48
48
48
1
49
49
49
1
50
50
50
1
51
51
51
1
52
52
52
1
56
56
56
1
57
57
57
1
58
58
58
1
59
59
59
1

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Luck, Tony 
> Basically all cache indices carry the APIC ID of the core, so L1D on
> CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same
> ID.
> 
> How does that look on a CAT system? Do all the different cache levels
> get different IDs?

For CAT we only need the IDs to be unique at each level. Our tentative
syntax for the schema file for CAT looks like this (for a theoretical
system supporting CAT in both L2 and L3 with two L3 caches and eight L2 caches)

L3:id0=fff;id1=ff0
L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0

We wondered about using cpu numbers (i.e. when we say id0 on the "L3"
line we mean the L3 cache that is used by cpu0 (and a bunch of other
cpus) and on the L2 line it means the L2 cache shared by cpu0 (and its
hyperthread core buddy).  But that gets weird with hot plug. cpu0 may
be offline, but the caches it shares still exist.

-Tony

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Luck, Tony 
> Basically all cache indices carry the APIC ID of the core, so L1D on
> CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same
> ID.
> 
> How does that look on a CAT system? Do all the different cache levels
> get different IDs?

For CAT we only need the IDs to be unique at each level. Our tentative
syntax for the schema file for CAT looks like this (for a theoretical
system supporting CAT in both L2 and L3 with two L3 caches and eight L2 caches)

L3:id0=fff;id1=ff0
L2:id0=3;id1=c;id2=30;id3=c0;id4=3;id5=c;id6=30;id7=c0

We wondered about using cpu numbers (i.e. when we say id0 on the "L3"
line we mean the L3 cache that is used by cpu0 (and a bunch of other
cpus) and on the L2 line it means the L2 cache shared by cpu0 (and its
hyperthread core buddy).  But that gets weird with hot plug. cpu0 may
be offline, but the caches it shares still exist.

-Tony

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote:
> Here's the situation.  We have lots of (mostly) independent caches on a 
> system.
> The L3 cache (also called LLC - Last Level Cache - in some documentation) is
> usually shared by all cpus on a physical socket. The L1 and L2 caches are
> typically local to a core, so only shared by the hyperthreads on a core.
> But I say "usually" and "typically" because the architecture doesn't require
> that. We could have multiple separate L3 caches on a socket with a subset of
> cpus assigned to each of them. We could have an L2 cache that is shared by
> two or more cores.

Right, so I'm presuming we don't want to make it special to the LLC but
be generic and have any cache level have an ID.

And, since we simply call it cache, how about we drop the "node" thing
and simply talk about cache and it having an ID. We say it is unique on
the system and the cache with ID X is local to only thread X and the
cache with ID Y is shared by threads Y_0, ... Y_k. And so on...

How does that sound?

Struct doc will have then:

 /**
  * struct cacheinfo - represent a cache leaf node
+ * @id: This cache's ID. ID is unique on the platform.

?

which begs the question, does get_cache_id() give unique IDs for all
caches in the hierarchy on the system?

Because I tried this patch quickly in kvm and it was of course wrong but
it hints at that important question:

cpu0/cache/index0/id:0
cpu0/cache/index1/id:0
cpu0/cache/index2/id:0
cpu1/cache/index0/id:1
cpu1/cache/index1/id:1
cpu1/cache/index2/id:1
cpu2/cache/index0/id:2
cpu2/cache/index1/id:2
cpu2/cache/index2/id:2
cpu3/cache/index0/id:3
cpu3/cache/index1/id:3
cpu3/cache/index2/id:3
cpu4/cache/index0/id:4
cpu4/cache/index1/id:4
cpu4/cache/index2/id:4
cpu5/cache/index0/id:5
cpu5/cache/index1/id:5
cpu5/cache/index2/id:5
cpu6/cache/index0/id:6
cpu6/cache/index1/id:6
cpu6/cache/index2/id:6
cpu7/cache/index0/id:7
cpu7/cache/index1/id:7
cpu7/cache/index2/id:7

Basically all cache indices carry the APIC ID of the core, so L1D on
CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same
ID.

How does that look on a CAT system? Do all the different cache levels
get different IDs?

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote:
> Here's the situation.  We have lots of (mostly) independent caches on a 
> system.
> The L3 cache (also called LLC - Last Level Cache - in some documentation) is
> usually shared by all cpus on a physical socket. The L1 and L2 caches are
> typically local to a core, so only shared by the hyperthreads on a core.
> But I say "usually" and "typically" because the architecture doesn't require
> that. We could have multiple separate L3 caches on a socket with a subset of
> cpus assigned to each of them. We could have an L2 cache that is shared by
> two or more cores.

Right, so I'm presuming we don't want to make it special to the LLC but
be generic and have any cache level have an ID.

And, since we simply call it cache, how about we drop the "node" thing
and simply talk about cache and it having an ID. We say it is unique on
the system and the cache with ID X is local to only thread X and the
cache with ID Y is shared by threads Y_0, ... Y_k. And so on...

How does that sound?

Struct doc will have then:

 /**
  * struct cacheinfo - represent a cache leaf node
+ * @id: This cache's ID. ID is unique on the platform.

?

which begs the question, does get_cache_id() give unique IDs for all
caches in the hierarchy on the system?

Because I tried this patch quickly in kvm and it was of course wrong but
it hints at that important question:

cpu0/cache/index0/id:0
cpu0/cache/index1/id:0
cpu0/cache/index2/id:0
cpu1/cache/index0/id:1
cpu1/cache/index1/id:1
cpu1/cache/index2/id:1
cpu2/cache/index0/id:2
cpu2/cache/index1/id:2
cpu2/cache/index2/id:2
cpu3/cache/index0/id:3
cpu3/cache/index1/id:3
cpu3/cache/index2/id:3
cpu4/cache/index0/id:4
cpu4/cache/index1/id:4
cpu4/cache/index2/id:4
cpu5/cache/index0/id:5
cpu5/cache/index1/id:5
cpu5/cache/index2/id:5
cpu6/cache/index0/id:6
cpu6/cache/index1/id:6
cpu6/cache/index2/id:6
cpu7/cache/index0/id:7
cpu7/cache/index1/id:7
cpu7/cache/index2/id:7

Basically all cache indices carry the APIC ID of the core, so L1D on
CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same
ID.

How does that look on a CAT system? Do all the different cache levels
get different IDs?

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Luck, Tony 
On Fri, Jul 01, 2016 at 12:21:43PM +0200, Borislav Petkov wrote:
> On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote:
> > From: Fenghua Yu 
> > 
> > Each cache node is described by cacheinfo and is a unique node across
> 
> What is a cache node?

Clearly not a good name for the concept we are trying to communicate here.
Better suggestions welcome!

Here's the situation.  We have lots of (mostly) independent caches on a system.
The L3 cache (also called LLC - Last Level Cache - in some documentation) is
usually shared by all cpus on a physical socket. The L1 and L2 caches are
typically local to a core, so only shared by the hyperthreads on a core.
But I say "usually" and "typically" because the architecture doesn't require
that. We could have multiple separate L3 caches on a socket with a subset of
cpus assigned to each of them. We could have an L2 cache that is shared by
two or more cores.

/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_{list,map} allow for
arbitrary sharing schemes and tell you which caches are shared among which
groups of Linux logical cpus.

What we don't have is a *name* for each cache.

CAT (Intel Cache Allocation Technology) allows us to partition caches
on a per task basis. E.g. process A can only use 20% of the L3 cache on
socket0, process B can use 40% (that doesn't overlap with the 20% assigned
to process A - or perhaps does overlap - the feature is quite versatile).
But since caches aren't necessarily mapped to sockets or cores, we need a
name for each cache.


> And since this patch adds the generic functionality and then enables it
> on x86, it should be split into two patches.

Mea culpa.  Fenghua had split this as you suggest, and I said "with just
23 lines added this can be one patch". Sorry Fenghua.

-Tony

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Luck, Tony 
On Fri, Jul 01, 2016 at 12:21:43PM +0200, Borislav Petkov wrote:
> On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote:
> > From: Fenghua Yu 
> > 
> > Each cache node is described by cacheinfo and is a unique node across
> 
> What is a cache node?

Clearly not a good name for the concept we are trying to communicate here.
Better suggestions welcome!

Here's the situation.  We have lots of (mostly) independent caches on a system.
The L3 cache (also called LLC - Last Level Cache - in some documentation) is
usually shared by all cpus on a physical socket. The L1 and L2 caches are
typically local to a core, so only shared by the hyperthreads on a core.
But I say "usually" and "typically" because the architecture doesn't require
that. We could have multiple separate L3 caches on a socket with a subset of
cpus assigned to each of them. We could have an L2 cache that is shared by
two or more cores.

/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_{list,map} allow for
arbitrary sharing schemes and tell you which caches are shared among which
groups of Linux logical cpus.

What we don't have is a *name* for each cache.

CAT (Intel Cache Allocation Technology) allows us to partition caches
on a per task basis. E.g. process A can only use 20% of the L3 cache on
socket0, process B can use 40% (that doesn't overlap with the 20% assigned
to process A - or perhaps does overlap - the feature is quite versatile).
But since caches aren't necessarily mapped to sockets or cores, we need a
name for each cache.


> And since this patch adds the generic functionality and then enables it
> on x86, it should be split into two patches.

Mea culpa.  Fenghua had split this as you suggest, and I said "with just
23 lines added this can be one patch". Sorry Fenghua.

-Tony

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote:
> From: Fenghua Yu 
> 
> Each cache node is described by cacheinfo and is a unique node across

What is a cache node?

> the platform. But there is no id for a cache node. We introduce cache ID
> to identify a cache node.
> 
> Intel Cache Allocation Technology (CAT) allows some control on the
> allocation policy within each cache that it controls. We need a unique
> cache ID for each cache level to allow the user to specify which
> controls are applied to which cache.
> 
> The cache id is first enabled on x86. It can be enabled on other platforms
> as well. The cache id is not necessary contiguous.
> 
> Add an "id" entry to /sys/devices/system/cpu/cpu*/cache/index*/
> 
> Signed-off-by: Fenghua Yu 
> ---
>  arch/x86/kernel/cpu/intel_cacheinfo.c | 21 +
>  drivers/base/cacheinfo.c  |  5 +
>  include/linux/cacheinfo.h |  3 +++
>  3 files changed, 29 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
> b/arch/x86/kernel/cpu/intel_cacheinfo.c
> index de6626c..aefc1e5 100644
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -153,6 +153,7 @@ struct _cpuid4_info_regs {
>   union _cpuid4_leaf_eax eax;
>   union _cpuid4_leaf_ebx ebx;
>   union _cpuid4_leaf_ecx ecx;
> + unsigned int id;
>   unsigned long size;
>   struct amd_northbridge *nb;
>  };
> @@ -894,6 +895,9 @@ static void __cache_cpumap_setup(unsigned int cpu, int 
> index,
>  static void ci_leaf_init(struct cacheinfo *this_leaf,
>struct _cpuid4_info_regs *base)
>  {
> + this_leaf->id = base->id;
> + /* Set CACHE_ID bit in attributes to enable cache id in x86. */

No need for that comment.

> + this_leaf->attributes = CACHE_ID;
>   this_leaf->level = base->eax.split.level;
>   this_leaf->type = cache_type_map[base->eax.split.type];
>   this_leaf->coherency_line_size =
> @@ -920,6 +924,22 @@ static int __init_cache_level(unsigned int cpu)
>   return 0;
>  }
>  
> +/*
> + * The max shared threads number comes from CPUID.4:EAX[25-14] with input
> + * ECX as cache index. Then right shift apicid by the number's order to get
> + * cache id for this cache node.
> + */
> +static void get_cache_id(int cpu, struct _cpuid4_info_regs *id4_regs)
> +{
> + struct cpuinfo_x86 *c = _data(cpu);
> + unsigned long num_threads_sharing;
> + int index_msb;
> +
> + num_threads_sharing = 1 + id4_regs->eax.split.num_threads_sharing;
> + index_msb = get_count_order(num_threads_sharing);
> + id4_regs->id = c->apicid >> index_msb;
> +}
> +
>  static int __populate_cache_leaves(unsigned int cpu)
>  {
>   unsigned int idx, ret;
> @@ -931,6 +951,7 @@ static int __populate_cache_leaves(unsigned int cpu)
>   ret = cpuid4_cache_lookup_regs(idx, _regs);
>   if (ret)
>   return ret;
> + get_cache_id(cpu, _regs);
>   ci_leaf_init(this_leaf++, _regs);
>   __cache_cpumap_setup(cpu, idx, _regs);
>   }
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index e9fd32e..2a21c15 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -233,6 +233,7 @@ static ssize_t file_name##_show(struct device *dev,   
> \
>   return sprintf(buf, "%u\n", this_leaf->object); \
>  }
>  
> +show_one(id, id);
>  show_one(level, level);
>  show_one(coherency_line_size, coherency_line_size);
>  show_one(number_of_sets, number_of_sets);
> @@ -314,6 +315,7 @@ static ssize_t write_policy_show(struct device *dev,
>   return n;
>  }
>  
> +static DEVICE_ATTR_RO(id);
>  static DEVICE_ATTR_RO(level);
>  static DEVICE_ATTR_RO(type);
>  static DEVICE_ATTR_RO(coherency_line_size);
> @@ -327,6 +329,7 @@ static DEVICE_ATTR_RO(shared_cpu_list);
>  static DEVICE_ATTR_RO(physical_line_partition);
>  
>  static struct attribute *cache_default_attrs[] = {
> + _attr_id.attr,
>   _attr_type.attr,
>   _attr_level.attr,
>   _attr_shared_cpu_map.attr,
> @@ -350,6 +353,8 @@ cache_default_attrs_is_visible(struct kobject *kobj,
>   const struct cpumask *mask = _leaf->shared_cpu_map;
>   umode_t mode = attr->mode;
>  
> + if ((attr == _attr_id.attr) && this_leaf->attributes & CACHE_ID)
> + return mode;
>   if ((attr == _attr_type.attr) && this_leaf->type)
>   return mode;
>   if ((attr == _attr_level.attr) && this_leaf->level)
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index 2189935..16e5573 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -18,6 +18,7 @@ enum cache_type {
>  
>  /**
>   * struct cacheinfo - represent a cache leaf node
> + * @id: id of this cache node. This is unique id across the platform.

So you need to explain what a "cache node" is. Especially

Re: [PATCH] cacheinfo: Introduce cache id

2016-07-01 Thread Borislav Petkov 
On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote:
> From: Fenghua Yu 
> 
> Each cache node is described by cacheinfo and is a unique node across

What is a cache node?

> the platform. But there is no id for a cache node. We introduce cache ID
> to identify a cache node.
> 
> Intel Cache Allocation Technology (CAT) allows some control on the
> allocation policy within each cache that it controls. We need a unique
> cache ID for each cache level to allow the user to specify which
> controls are applied to which cache.
> 
> The cache id is first enabled on x86. It can be enabled on other platforms
> as well. The cache id is not necessary contiguous.
> 
> Add an "id" entry to /sys/devices/system/cpu/cpu*/cache/index*/
> 
> Signed-off-by: Fenghua Yu 
> ---
>  arch/x86/kernel/cpu/intel_cacheinfo.c | 21 +
>  drivers/base/cacheinfo.c  |  5 +
>  include/linux/cacheinfo.h |  3 +++
>  3 files changed, 29 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
> b/arch/x86/kernel/cpu/intel_cacheinfo.c
> index de6626c..aefc1e5 100644
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -153,6 +153,7 @@ struct _cpuid4_info_regs {
>   union _cpuid4_leaf_eax eax;
>   union _cpuid4_leaf_ebx ebx;
>   union _cpuid4_leaf_ecx ecx;
> + unsigned int id;
>   unsigned long size;
>   struct amd_northbridge *nb;
>  };
> @@ -894,6 +895,9 @@ static void __cache_cpumap_setup(unsigned int cpu, int 
> index,
>  static void ci_leaf_init(struct cacheinfo *this_leaf,
>struct _cpuid4_info_regs *base)
>  {
> + this_leaf->id = base->id;
> + /* Set CACHE_ID bit in attributes to enable cache id in x86. */

No need for that comment.

> + this_leaf->attributes = CACHE_ID;
>   this_leaf->level = base->eax.split.level;
>   this_leaf->type = cache_type_map[base->eax.split.type];
>   this_leaf->coherency_line_size =
> @@ -920,6 +924,22 @@ static int __init_cache_level(unsigned int cpu)
>   return 0;
>  }
>  
> +/*
> + * The max shared threads number comes from CPUID.4:EAX[25-14] with input
> + * ECX as cache index. Then right shift apicid by the number's order to get
> + * cache id for this cache node.
> + */
> +static void get_cache_id(int cpu, struct _cpuid4_info_regs *id4_regs)
> +{
> + struct cpuinfo_x86 *c = _data(cpu);
> + unsigned long num_threads_sharing;
> + int index_msb;
> +
> + num_threads_sharing = 1 + id4_regs->eax.split.num_threads_sharing;
> + index_msb = get_count_order(num_threads_sharing);
> + id4_regs->id = c->apicid >> index_msb;
> +}
> +
>  static int __populate_cache_leaves(unsigned int cpu)
>  {
>   unsigned int idx, ret;
> @@ -931,6 +951,7 @@ static int __populate_cache_leaves(unsigned int cpu)
>   ret = cpuid4_cache_lookup_regs(idx, _regs);
>   if (ret)
>   return ret;
> + get_cache_id(cpu, _regs);
>   ci_leaf_init(this_leaf++, _regs);
>   __cache_cpumap_setup(cpu, idx, _regs);
>   }
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index e9fd32e..2a21c15 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -233,6 +233,7 @@ static ssize_t file_name##_show(struct device *dev,   
> \
>   return sprintf(buf, "%u\n", this_leaf->object); \
>  }
>  
> +show_one(id, id);
>  show_one(level, level);
>  show_one(coherency_line_size, coherency_line_size);
>  show_one(number_of_sets, number_of_sets);
> @@ -314,6 +315,7 @@ static ssize_t write_policy_show(struct device *dev,
>   return n;
>  }
>  
> +static DEVICE_ATTR_RO(id);
>  static DEVICE_ATTR_RO(level);
>  static DEVICE_ATTR_RO(type);
>  static DEVICE_ATTR_RO(coherency_line_size);
> @@ -327,6 +329,7 @@ static DEVICE_ATTR_RO(shared_cpu_list);
>  static DEVICE_ATTR_RO(physical_line_partition);
>  
>  static struct attribute *cache_default_attrs[] = {
> + _attr_id.attr,
>   _attr_type.attr,
>   _attr_level.attr,
>   _attr_shared_cpu_map.attr,
> @@ -350,6 +353,8 @@ cache_default_attrs_is_visible(struct kobject *kobj,
>   const struct cpumask *mask = _leaf->shared_cpu_map;
>   umode_t mode = attr->mode;
>  
> + if ((attr == _attr_id.attr) && this_leaf->attributes & CACHE_ID)
> + return mode;
>   if ((attr == _attr_type.attr) && this_leaf->type)
>   return mode;
>   if ((attr == _attr_level.attr) && this_leaf->level)
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index 2189935..16e5573 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -18,6 +18,7 @@ enum cache_type {
>  
>  /**
>   * struct cacheinfo - represent a cache leaf node
> + * @id: id of this cache node. This is unique id across the platform.

So you need to explain what a "cache node" is. Especially since this is
generic code and other arches