Add new aux vector entries for cache size and shape #57

Closed
opened 7 years ago by wschmidt-ibm · 2 comments
wschmidt-ibm commented 7 years ago (Migrated from github.com)

Section 4.1.2.3 should reflect this recent new agreement between glibc and the kernel:

/*

  • 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_CACHESHAPE 41
#define AT_L1D_CACHESIZE 42
#define AT_L1D_CACHESHAPE 43
#define AT_L2_CACHESIZE 44
#define AT_L2_CACHESHAPE 45
#define AT_L3_CACHESIZE 46
#define AT_L3_CACHESHAPE 47

Section 4.1.2.3 should reflect this recent new agreement between glibc and the kernel: /* * 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_CACHESHAPE 41 #define AT_L1D_CACHESIZE 42 #define AT_L1D_CACHESHAPE 43 #define AT_L2_CACHESIZE 44 #define AT_L2_CACHESHAPE 45 #define AT_L3_CACHESIZE 46 #define AT_L3_CACHESHAPE 47
wschmidt-ibm commented 7 years ago (Migrated from github.com)

Tulio reported an issue with Ben's patches on the linuxppc-dev@lists.ozlabs.org
list:

These names will clash with the other ones defined by alpha and sh:

/* Shapes of the caches. Bits 0-3 contains associativity; bits 4-7 contains
log2 of line size; mask those to get cache size. */
#define AT_L1I_CACHESHAPE 34
#define AT_L1D_CACHESHAPE 35
#define AT_L2_CACHESHAPE 36
#define AT_L3_CACHESHAPE 37

Tulio reported an issue with Ben's patches on the linuxppc-dev@lists.ozlabs.org list: -- These names will clash with the other ones defined by alpha and sh: /* Shapes of the caches. Bits 0-3 contains associativity; bits 4-7 contains log2 of line size; mask those to get cache size. */ #define AT_L1I_CACHESHAPE 34 #define AT_L1D_CACHESHAPE 35 #define AT_L2_CACHESHAPE 36 #define AT_L3_CACHESHAPE 37 --
wschmidt-ibm commented 7 years ago (Migrated from github.com)

Refer to this patch message for the final version:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/152790.html

Refer to this patch message for the final version: https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/152790.html
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: systemsoftware/ELFv2-ABI#57
Loading…
There is no content yet.