Re: [PATCH] powerpc: fix sysconf support for cache geometries

[Paul Clarke <pc at us dot ibm dot com>]

On 06/15/2017 10:07 PM, Richard Henderson wrote:
> On 06/15/2017 04:53 PM, Paul Clarke wrote:
>> On 06/15/2017 04:03 PM, Richard Henderson wrote:
>>> On 06/15/2017 01:45 PM, Paul Clarke wrote:
>>> Any thoughts on falling back to AT_*CACHEBSIZE for _SC_LEVEL1_*CACHE_LINESIZE
>>> for older kernels where AT_L1*_CACHEGEOMETRY is not present?
>> 
>> Ben'll tell you (as he told me ;-) that those aren't the same thing.  The
>> former, "CACHEBSIZE", is the cache block size, which is the unit size for
>> cache operations (e.g. "Cache Block Touch", "Cache Block Clear", etc.).  The
>> latter, "CACHE_LINESIZE", is, well, the cache line size (with respect to
>> associativity, etc.).
> Yeah, yeah, but... show me where it's different, for L1, in practice.

Yep, I can't.

>> Did you want to respin your sysconf patch? I notice you also included L4,
> which always returns 0, a value, unlike my patch, which will fail (return -1,
> EINVAL). Yours may be preferred in that regard, since the "names" for the L4
> queries are not completely unknown.
> 
> -1 without EINVAL is, afaik, an indication that L4 does not exist.
> Whereas 0 indicates that we don't know.

No.  Per the manpage, "If name is invalid, -1 is returned, and errno is set to EINVAL.  Otherwise, the value returned is the value of the system resource and errno is not changed.  In the case of options, a positive value is returned if a queried option is available, and -1 if it is not."

With a valid "name", the return value is the value.  "options", above, has a special meaning, for "posixoptions(7)", so that phrase doesn't apply.

So, possible return values for L4 are >0 (exists) and =0 (doesn't).

> That said, I really don't care about the deep cache hierarchy, so I'm fine with 
> either as a result.

I think it's reasonable to include both of your changes:
- return the L1 cache block sizes if the L1 cache line sizes are not available
- return 0 for L4 (not -1/EINVAL)

PC