This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding cache shape info to powerpc


On Wed, 2016-08-17 at 10:36 +0200, Florian Weimer wrote:
> On 08/17/2016 06:42 AM, Benjamin Herrenschmidt wrote:
> > Hi !
> >
> > So there are pending requests to provide cache shape/geometry
> > information to user space via the aux vectors.
> >
> > This is done today by Alpha and SH using these:
> >
> > /* 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
> >
> > I have written some kernel code to do the same on powerpc, however I had
> > to change the format of the entries. 4 bits isn't sufficient to represent
> > modern cache associativities on some server chips.
> >
> > I've chosen this format. Is that ok with the community ? Can I still use
> > the same AT_* vector numbers or should I create new ones ?
> 
> If the old format was in mainline at any point (or in a vendor kernel, 
> but let's hope vendors don't do this anymore), you need to pick new numbers.

If we need new ones anyway, is there any reason for having to pack this
information?  Why can't we have separate define's for the individual
properties describing the shape?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]