linux-kernel - Re: [PATCH] cacheinfo: Introduce cache id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Jul 2016 19:27:43 +0200
From:	Borislav Petkov <bp@...e.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Fenghua Yu <fenghua.yu@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <h.peter.anvin@...el.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...gle.com>,
	Ravi V Shankar <ravi.v.shankar@...el.com>,
	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.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?

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)
--