| Message ID | 1486016558.4850.30.camel@kernel.crashing.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: > This adds AUX vectors for the L1I,D, L2 and L3 cache levels > providing for each cache level the size of the cache in bytes > and the geometry (line size and number of ways). > > We chose to not use the existing alpha/sh definition which > packs all the information in a single entry per cache level as > it is too restricted to represent some of the geometries used > on POWER. > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > --- > > v2. Remove some leftovers and fix 32-bit build > > Paul, can you test & ack this please ? It replaces the last patch of > my previous series (the rest is identical). Sorry for the delay on this, I totally missed this e-mail until this week. I tested this with the Power Functional Simulator (a.k.a. Mambo), with a fairly recent 4.9 kernel from the powerpc git tree. Using Mambo-P8, I see what I expect for cache line size, but associativity is 0: AT_L1I_CACHESIZE: 32768 (0x8000) AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 AT_L1D_CACHESIZE: 32768 (0x8000) AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 AT_L2_CACHESIZE: 524288 (0x80000) AT_L2_CACHEGEOMETRY: associativity 0; line size 128 AT_L3_CACHESIZE: 8388608 (0x800000) AT_L3_CACHEGEOMETRY: associativity 0; line size 128 ...shouldn't associativity be 8 for all levels? Using Mambo-P9, I don't get any cache sizes, and only L1 geometries, and no associativity: AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 PC
Paul Clarke <pc@us.ibm.com> writes: > On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: >> This adds AUX vectors for the L1I,D, L2 and L3 cache levels >> providing for each cache level the size of the cache in bytes >> and the geometry (line size and number of ways). >> >> We chose to not use the existing alpha/sh definition which >> packs all the information in a single entry per cache level as >> it is too restricted to represent some of the geometries used >> on POWER. >> >> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >> --- >> >> v2. Remove some leftovers and fix 32-bit build >> >> Paul, can you test & ack this please ? It replaces the last patch of >> my previous series (the rest is identical). > > Sorry for the delay on this, I totally missed this e-mail until this week. > > I tested this with the Power Functional Simulator (a.k.a. Mambo), with > a fairly recent 4.9 kernel from the powerpc git tree. You mean 4.9 plus this patch? > Using Mambo-P8, I see what I expect for cache line size, but associativity is 0: > AT_L1I_CACHESIZE: 32768 (0x8000) > AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 > AT_L1D_CACHESIZE: 32768 (0x8000) > AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 > AT_L2_CACHESIZE: 524288 (0x80000) > AT_L2_CACHEGEOMETRY: associativity 0; line size 128 > AT_L3_CACHESIZE: 8388608 (0x800000) > AT_L3_CACHEGEOMETRY: associativity 0; line size 128 > > ...shouldn't associativity be 8 for all levels? Yes. I fixed it in v3: http://patchwork.ozlabs.org/patch/723576/ Which is now merged in Linus tree, so please test that. Can you try the test program I wrote (which may also have bugs): http://patchwork.ozlabs.org/patch/724418/ cheers
On 03/02/2017 12:33 AM, Michael Ellerman wrote: > Paul Clarke <pc@us.ibm.com> writes: >> On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: >>> This adds AUX vectors for the L1I,D, L2 and L3 cache levels >>> providing for each cache level the size of the cache in bytes >>> and the geometry (line size and number of ways). >>> >>> We chose to not use the existing alpha/sh definition which >>> packs all the information in a single entry per cache level as >>> it is too restricted to represent some of the geometries used >>> on POWER. >>> >>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >>> --- >>> >>> v2. Remove some leftovers and fix 32-bit build >>> >>> Paul, can you test & ack this please ? It replaces the last patch of >>> my previous series (the rest is identical). >> >> Sorry for the delay on this, I totally missed this e-mail until this week. >> >> I tested this with the Power Functional Simulator (a.k.a. Mambo), with >> a fairly recent 4.9 kernel from the powerpc git tree. > > You mean 4.9 plus this patch? > >> Using Mambo-P8, I see what I expect for cache line size, but associativity is 0: >> AT_L1I_CACHESIZE: 32768 (0x8000) >> AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 >> AT_L1D_CACHESIZE: 32768 (0x8000) >> AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 >> AT_L2_CACHESIZE: 524288 (0x80000) >> AT_L2_CACHEGEOMETRY: associativity 0; line size 128 >> AT_L3_CACHESIZE: 8388608 (0x800000) >> AT_L3_CACHEGEOMETRY: associativity 0; line size 128 >> >> ...shouldn't associativity be 8 for all levels? > > Yes. > > I fixed it in v3: http://patchwork.ozlabs.org/patch/723576/ > > Which is now merged in Linus tree, so please test that. It's not working for me, but it's also very likely that I could be doing something stupid. Just pulling from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, it built (without the "systemsim" patches"), but wouldn't boot in Mambo (not because it couldn't find root...something else not fully explored). I checked out tag "v4.10", and that built (with the "systemsim" patches, Ben's 1-8 and your 9v3) and booted. On Mambo-P8, the device tree looks correct (to me), but the associativity is still 0. On P9, the device tree isn't correct, so I'm not sure what to expect. I added a bit more debug to my test: AT_L1I_CACHESIZE: 32768 (0x8000) getauxval(AT_L1I_CACHEGEOMETRY) = 0x0000000000000080 AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 AT_L1D_CACHESIZE: 32768 (0x8000) getauxval(AT_L1D_CACHEGEOMETRY) = 0x0000000000000080 AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 AT_L2_CACHESIZE: 524288 (0x80000) getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000080 AT_L2_CACHEGEOMETRY: associativity 0; line size 128 AT_L3_CACHESIZE: 8388608 (0x800000) getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000080 AT_L3_CACHEGEOMETRY: associativity 0; line size 128 When I use gdb, and break at main: (gdb) x/60gx ($r6) 0x3ffffffffca0: 0x0000000000000016 0x0000000000000016 0x3ffffffffcb0: 0x0000000000000016 0x0000000000000016 0x3ffffffffcc0: 0x0000000000000013 0x0000000000000080 0x3ffffffffcd0: 0x0000000000000014 0x0000000000000080 0x3ffffffffce0: 0x0000000000000015 0x0000000000000000 0x3ffffffffcf0: 0x0000000000000021 0x00003fffb7fa0000 0x3ffffffffd00: 0x0000000000000028 0x0000000000008000 0x3ffffffffd10: 0x0000000000000029 0x0000000000000080 0x3ffffffffd20: 0x000000000000002a 0x0000000000008000 0x3ffffffffd30: 0x000000000000002b 0x0000000000000080 0x3ffffffffd40: 0x000000000000002c 0x0000000000080000 0x3ffffffffd50: 0x000000000000002d 0x0000000000000080 0x3ffffffffd60: 0x000000000000002e 0x0000000000800000 0x3ffffffffd70: 0x000000000000002f 0x0000000000000080 and, looking at the device-tree: # for i in /proc/device-tree/cpus/PowerPC@0/*cache*; do echo $i; od -tx1 $i; done /proc/device-tree/cpus/PowerPC@0/d-cache-block-size 0000000 00 00 00 80 /proc/device-tree/cpus/PowerPC@0/d-cache-line-size 0000000 00 00 00 80 /proc/device-tree/cpus/PowerPC@0/d-cache-sets 0000000 00 00 00 04 /proc/device-tree/cpus/PowerPC@0/d-cache-size 0000000 00 00 80 00 /proc/device-tree/cpus/PowerPC@0/i-cache-block-size 0000000 00 00 00 80 /proc/device-tree/cpus/PowerPC@0/i-cache-line-size 0000000 00 00 00 80 /proc/device-tree/cpus/PowerPC@0/i-cache-sets 0000000 00 00 00 02 /proc/device-tree/cpus/PowerPC@0/i-cache-size 0000000 00 00 80 00 /proc/device-tree/cpus/PowerPC@0/l2-cache-size 0000000 00 0a 00 00 > > Can you try the test program I wrote (which may also have bugs): > > http://patchwork.ozlabs.org/patch/724418/ I couldn't get this working, either, so I'm probably doing something stupid. PC
Paul Clarke <pc@us.ibm.com> writes: > On 03/02/2017 12:33 AM, Michael Ellerman wrote: >> Paul Clarke <pc@us.ibm.com> writes: >>> On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: >>>> This adds AUX vectors for the L1I,D, L2 and L3 cache levels >>>> providing for each cache level the size of the cache in bytes >>>> and the geometry (line size and number of ways). >>>> >>>> We chose to not use the existing alpha/sh definition which >>>> packs all the information in a single entry per cache level as >>>> it is too restricted to represent some of the geometries used >>>> on POWER. >>>> >>>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >>>> --- >>>> >>>> v2. Remove some leftovers and fix 32-bit build >>>> >>>> Paul, can you test & ack this please ? It replaces the last patch of >>>> my previous series (the rest is identical). >>> >>> Sorry for the delay on this, I totally missed this e-mail until this week. >>> >>> I tested this with the Power Functional Simulator (a.k.a. Mambo), with >>> a fairly recent 4.9 kernel from the powerpc git tree. >> >> You mean 4.9 plus this patch? >> >>> Using Mambo-P8, I see what I expect for cache line size, but associativity is 0: >>> AT_L1I_CACHESIZE: 32768 (0x8000) >>> AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 >>> AT_L1D_CACHESIZE: 32768 (0x8000) >>> AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 >>> AT_L2_CACHESIZE: 524288 (0x80000) >>> AT_L2_CACHEGEOMETRY: associativity 0; line size 128 >>> AT_L3_CACHESIZE: 8388608 (0x800000) >>> AT_L3_CACHEGEOMETRY: associativity 0; line size 128 >>> >>> ...shouldn't associativity be 8 for all levels? >> >> Yes. >> >> I fixed it in v3: http://patchwork.ozlabs.org/patch/723576/ >> >> Which is now merged in Linus tree, so please test that. > > It's not working for me, but it's also very likely that I could be > doing something stupid. Just pulling from > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, it > built (without the "systemsim" patches"), but wouldn't boot in Mambo > (not because it couldn't find root...something else not fully > explored). Hmm OK, it's booting for me, but might depend on your config/toolchain etc. Linus' tree just before rc1 is a bit of a dangerous place to be. > I checked out tag "v4.10", and that built (with the > "systemsim" patches, Ben's 1-8 and your 9v3) and booted. I think you need my entire v3, ignore Ben's series. > On Mambo-P8, > the device tree looks correct (to me), but the associativity is still > 0. OK, I think if you use the full v3 the associativity will be fixed. Though it might still be wrong, because the kernel code hard codes the values on P8 bare metal, because on real machines (running skiboot) the values provided in the device tree are wrong. Hopefully those hard coded values are also correct on p8 mambo, but we should probably check. See: https://git.kernel.org/torvalds/c/608b42140e96 > On P9, the device tree isn't correct, so I'm not sure what to expect. Junk :) On P9 it all comes from the device tree so if that's wrong the AUX vectors will definitely be wrong. >> Can you try the test program I wrote (which may also have bugs): >> >> http://patchwork.ozlabs.org/patch/724418/ > > I couldn't get this working, either, so I'm probably doing something stupid. Did you apply the first patch of the series also? If you apply those on top of v4.10 and then do: $ make TARGETS=powerpc ARCH=powerpc CROSS_COMPILE=ppc64le- -C tools/testing/selftests You should end up with: $ file tools/testing/selftests/powerpc/cache_shape/cache_shape tools/testing/selftests/powerpc/cache_shape/cache_shape: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3535b7ab6ec854eceaa7ad23456a087111b51583, not stripped cheers
On 03/02/2017 10:01 PM, Michael Ellerman wrote: > Paul Clarke <pc@us.ibm.com> writes: >> On 03/02/2017 12:33 AM, Michael Ellerman wrote: >>> Paul Clarke <pc@us.ibm.com> writes: >>>> On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: >>>>> This adds AUX vectors for the L1I,D, L2 and L3 cache levels >>>>> providing for each cache level the size of the cache in bytes >>>>> and the geometry (line size and number of ways). >>>>> >>>>> We chose to not use the existing alpha/sh definition which >>>>> packs all the information in a single entry per cache level as >>>>> it is too restricted to represent some of the geometries used >>>>> on POWER. >>>>> >>>>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >>>>> --- >>>>> >>>>> v2. Remove some leftovers and fix 32-bit build >>>>> >>>>> Paul, can you test & ack this please ? It replaces the last patch of >>>>> my previous series (the rest is identical). >>>> >>>> Sorry for the delay on this, I totally missed this e-mail until this week. >>>> >>>> I tested this with the Power Functional Simulator (a.k.a. Mambo), with >>>> a fairly recent 4.9 kernel from the powerpc git tree. >>> >>> You mean 4.9 plus this patch? >>> >>>> Using Mambo-P8, I see what I expect for cache line size, but associativity is 0: >>>> AT_L1I_CACHESIZE: 32768 (0x8000) >>>> AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 >>>> AT_L1D_CACHESIZE: 32768 (0x8000) >>>> AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 >>>> AT_L2_CACHESIZE: 524288 (0x80000) >>>> AT_L2_CACHEGEOMETRY: associativity 0; line size 128 >>>> AT_L3_CACHESIZE: 8388608 (0x800000) >>>> AT_L3_CACHEGEOMETRY: associativity 0; line size 128 >>>> >>>> ...shouldn't associativity be 8 for all levels? >>> >>> Yes. >>> >>> I fixed it in v3: http://patchwork.ozlabs.org/patch/723576/ >>> >>> Which is now merged in Linus tree, so please test that. >> >> It's not working for me, but it's also very likely that I could be >> doing something stupid. Just pulling from >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, it >> built (without the "systemsim" patches"), but wouldn't boot in Mambo >> (not because it couldn't find root...something else not fully >> explored). > > Hmm OK, it's booting for me, but might depend on your config/toolchain > etc. Linus' tree just before rc1 is a bit of a dangerous place to be. > >> I checked out tag "v4.10", and that built (with the >> "systemsim" patches, Ben's 1-8 and your 9v3) and booted. > > I think you need my entire v3, ignore Ben's series. > >> On Mambo-P8, >> the device tree looks correct (to me), but the associativity is still >> 0. > > OK, I think if you use the full v3 the associativity will be fixed. > > Though it might still be wrong, because the kernel code hard codes the > values on P8 bare metal, because on real machines (running skiboot) the > values provided in the device tree are wrong. > > Hopefully those hard coded values are also correct on p8 mambo, but we > should probably check. > > See: https://git.kernel.org/torvalds/c/608b42140e96 OK, thanks for your help. All is working as expected now. mambo-p8 looks fine: -- AT_L1I_CACHESIZE: 32768 (0x8000) getauxval(AT_L1I_CACHEGEOMETRY) = 0x0000000000080080 AT_L1I_CACHEGEOMETRY: associativity 8; line size 128 AT_L1D_CACHESIZE: 32768 (0x8000) getauxval(AT_L1D_CACHEGEOMETRY) = 0x0000000000080080 AT_L1D_CACHEGEOMETRY: associativity 8; line size 128 AT_L2_CACHESIZE: 524288 (0x80000) getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000080080 AT_L2_CACHEGEOMETRY: associativity 8; line size 128 AT_L3_CACHESIZE: 8388608 (0x800000) getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000080080 AT_L3_CACHEGEOMETRY: associativity 8; line size 128 -- >> On P9, the device tree isn't correct, so I'm not sure what to expect. > > Junk :) > > On P9 it all comes from the device tree so if that's wrong the AUX > vectors will definitely be wrong. mambo-p9 is still falling victim to the device-tree, but "working": -- getauxval(AT_L1I_CACHEGEOMETRY) = 0x0000000000000080 AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 getauxval(AT_L1D_CACHEGEOMETRY) = 0x0000000000000080 AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000000 getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000000 -- >>> Can you try the test program I wrote (which may also have bugs): >>> >>> http://patchwork.ozlabs.org/patch/724418/ >> >> I couldn't get this working, either, so I'm probably doing something stupid. > > Did you apply the first patch of the series also? I did now, and it works, with expected results: P8: -- # ./cache_shape test: cache_shape tags: git_version:v4.10-0-gc470abd-dirty L1I cache size: 0x8000 32768B 32K L1I line size: 0x80 8-way associative L1D cache size: 0x8000 32768B 32K L1D line size: 0x80 8-way associative L2 cache size: 0x80000 524288B 512K L2 line size: 0x80 8-way associative L3 cache size: 0x800000 8388608B 8192K L3 line size: 0x80 8-way associative success: cache_shape -- P9 (with bad device-tree): -- # ./cache_shape test: cache_shape tags: git_version:v4.10-0-gc470abd-dirty L1I cache size: 0 0B 0K L1I line size: 0x80 fully associative L1D cache size: 0 0B 0K L1D line size: 0x80 fully associative L2 cache size: 0 0B 0K L2 line size: 0 fully associative L3 cache size: 0 0B 0K L3 line size: 0 fully associative success: cache_shape -- Do you want me to Ack your v3 patch set in that thread? PC
On Fri, 2017-03-03 at 07:51 -0600, Paul Clarke wrote: > > On P9 it all comes from the device tree so if that's wrong the AUX > > vectors will definitely be wrong. > > mambo-p9 is still falling victim to the device-tree, but "working": > -- > getauxval(AT_L1I_CACHEGEOMETRY) = 0x0000000000000080 > AT_L1I_CACHEGEOMETRY: associativity 0; line size 128 > getauxval(AT_L1D_CACHEGEOMETRY) = 0x0000000000000080 > AT_L1D_CACHEGEOMETRY: associativity 0; line size 128 > getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000000 > getauxval(AT_L2_CACHEGEOMETRY) = 0x0000000000000000 > -- The mambo device-tree comes from the mambo own internals afaik. On real HW, the values come from HDAT. If they are wrong we need the HostBoot guys to fix them. Cheers, Ben.
Paul Clarke <pc@us.ibm.com> writes: > P9 (with bad device-tree): > -- > # ./cache_shape > test: cache_shape > tags: git_version:v4.10-0-gc470abd-dirty > L1I cache size: 0 0B 0K > L1I line size: 0x80 fully associative > L1D cache size: 0 0B 0K > L1D line size: 0x80 fully associative > L2 cache size: 0 0B 0K > L2 line size: 0 fully associative > L3 cache size: 0 0B 0K > L3 line size: 0 fully associative > success: cache_shape > -- Hmm, which p9 mambo is this? I get: test: cache_shape tags: git_version:v4.10-10927-g0a55d1671c33 L1I cache size: 0x8000 32768B 32K L1I line size: 0x80 128-way associative L1D cache size: 0x8000 32768B 32K L1D line size: 0x80 128-way associative L2 cache size: 0 0B 0K L2 line size: 0 fully associative L3 cache size: 0 0B 0K L3 line size: 0 fully associative success: cache_shape So that looks OK, other than that here is no L2/L3 info. I'm using mambo commit e0c03c93c6d14c5f842840cc4ac4183cb25e123b. > > Do you want me to Ack your v3 patch set in that thread? No don't bother, it's already merged so your ack wouldn't get included in the git history. This mail thread is record enough that it got tested by someone other than me. Thanks for testing. cheers
On Mon, Mar 06, 2017 at 04:46:46PM +1100, Michael Ellerman wrote: > Hmm, which p9 mambo is this? I get: > > test: cache_shape > tags: git_version:v4.10-10927-g0a55d1671c33 > L1I cache size: 0x8000 32768B 32K > L1I line size: 0x80 128-way associative > L1D cache size: 0x8000 32768B 32K > L1D line size: 0x80 128-way associative > L2 cache size: 0 0B 0K > L2 line size: 0 fully associative > L3 cache size: 0 0B 0K > L3 line size: 0 fully associative > success: cache_shape > > So that looks OK, other than that here is no L2/L3 info. 128 ways? Looks okay? Erm... Segher
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h index d7cf60f..5a90292 100644 --- a/arch/powerpc/include/asm/cache.h +++ b/arch/powerpc/include/asm/cache.h @@ -38,6 +38,7 @@ struct ppc_cache_info { u32 log_block_size; u32 blocks_per_page; u32 sets; + u32 assoc; }; struct ppc64_caches { diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h index 730c27e..93b9b84 100644 --- a/arch/powerpc/include/asm/elf.h +++ b/arch/powerpc/include/asm/elf.h @@ -136,6 +136,25 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm, #endif /* CONFIG_SPU_BASE */ +#ifdef CONFIG_PPC64 + +#define get_cache_geometry(level) \ + (ppc64_caches.level.assoc << 16 | ppc64_caches.level.line_size) + +#define ARCH_DLINFO_CACHE_GEOMETRY \ + NEW_AUX_ENT(AT_L1I_CACHESIZE, ppc64_caches.l1i.size); \ + NEW_AUX_ENT(AT_L1I_CACHEGEOMETRY, get_cache_geometry(l1i)); \ + NEW_AUX_ENT(AT_L1D_CACHESIZE, ppc64_caches.l1i.size); \ + NEW_AUX_ENT(AT_L1D_CACHEGEOMETRY, get_cache_geometry(l1i)); \ + NEW_AUX_ENT(AT_L2_CACHESIZE, ppc64_caches.l2.size); \ + NEW_AUX_ENT(AT_L2_CACHEGEOMETRY, get_cache_geometry(l2)); \ + NEW_AUX_ENT(AT_L3_CACHESIZE, ppc64_caches.l3.size); \ + NEW_AUX_ENT(AT_L3_CACHEGEOMETRY, get_cache_geometry(l3)) + +#else +#define ARCH_DLINFO_CACHE_GEOMETRY +#endif + /* * The requirements here are: * - keep the final alignment of sp (sp & 0xf) @@ -156,6 +175,7 @@ do { \ NEW_AUX_ENT(AT_ICACHEBSIZE, icache_bsize); \ NEW_AUX_ENT(AT_UCACHEBSIZE, ucache_bsize); \ VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso_base); \ + ARCH_DLINFO_CACHE_GEOMETRY; \ } while (0) #endif /* _ASM_POWERPC_ELF_H */ diff --git a/arch/powerpc/include/uapi/asm/auxvec.h b/arch/powerpc/include/uapi/asm/auxvec.h index ce17d2c..be6e94e 100644 --- a/arch/powerpc/include/uapi/asm/auxvec.h +++ b/arch/powerpc/include/uapi/asm/auxvec.h @@ -16,6 +16,37 @@ */ #define AT_SYSINFO_EHDR 33 -#define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */ +/* + * AT_*CACHEBSIZE above represent the cache *block* size which is + * the size that is affected by the cache management instructions. + * + * It doesn't nececssarily matches the cache *line* size which is + * more of a performance tuning hint. Additionally the latter can + * be different for the different cache levels. + * + * The set of entries below represent more extensive information + * about the caches, in the form of two entry per cache type, + * one entry containing the cache size in bytes, and the other + * containing the cache line size in bytes in the bottom 16 bits + * and the cache associativity in the next 16 bits. + * + * The associativity is such that if N is the 16-bit value, the + * cache is N way set associative. A value if 0xffff means fully + * associative, a value of 1 means directly mapped. + * + * For all these fields, a value of 0 means that the information + * is not known. + */ + +#define AT_L1I_CACHESIZE 40 +#define AT_L1I_CACHEGEOMETRY 41 +#define AT_L1D_CACHESIZE 42 +#define AT_L1D_CACHEGEOMETRY 43 +#define AT_L2_CACHESIZE 44 +#define AT_L2_CACHEGEOMETRY 45 +#define AT_L3_CACHESIZE 46 +#define AT_L3_CACHEGEOMETRY 47 + +#define AT_VECTOR_SIZE_ARCH 14 /* entries in ARCH_DLINFO */ #endif diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 8060c7c..57f2e5f 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -459,6 +459,10 @@ static bool __init parse_cache_info(struct device_node *np, info->block_size = bsize; info->log_block_size = __ilog2(bsize); info->blocks_per_page = PAGE_SIZE / bsize; + if (sets == 0) + info->assoc = 0xffff; + else + info->assoc = size / (sets * lsize); return success; }
This adds AUX vectors for the L1I,D, L2 and L3 cache levels providing for each cache level the size of the cache in bytes and the geometry (line size and number of ways). We chose to not use the existing alpha/sh definition which packs all the information in a single entry per cache level as it is too restricted to represent some of the geometries used on POWER. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- v2. Remove some leftovers and fix 32-bit build Paul, can you test & ack this please ? It replaces the last patch of my previous series (the rest is identical). arch/powerpc/include/asm/cache.h | 1 + arch/powerpc/include/asm/elf.h | 20 ++++++++++++++++++++ arch/powerpc/include/uapi/asm/auxvec.h | 33 ++++++++++++++++++++++++++++++++- arch/powerpc/kernel/setup_64.c | 4 ++++ 4 files changed, 57 insertions(+), 1 deletion(-)