[ltt-dev] liburcu cache line size

[alexandre.montplaisir@polymtl.ca (Alexandre Montplaisir)]

On 10-08-17 04:27 PM, Mathieu Desnoyers wrote:
> * Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
>    
>> On 10-08-17 03:54 PM, Mathieu Desnoyers wrote:
>>      
>   [...]
>    
>>> Oh, and by the way, given that these are arrays made of one variable per
>>> cpu, the extra space allocated will not consume extra cache lines in any
>>> of the CPU. We're just wasting a bit a memory here, not adding to cache
>>> pressure.
>>>
>>> Mathieu
>>>        
>> Sorry to chime in, but wouldn't padding to 128 bytes on architectures
>> with 64-byte cache lines "waste" an extra line every time, thus
>> indirectly adding to cache pressure?
>>      
> A cache line is only used if the data located in that cache line is
> touched. If we only have padding in the second half of the 128 bytes,
> then the associated 64 bytes cache line is never fetched by the cpu.
>
> But reality can be a bit different when we speak of sequential accesses
> with prefetching. However, this apply well to randomly-accessed memory.
>
> Does that make sense ?
>
>    
Yes, thanks for the explanation!

I see now why we *clearly* don't want the align attribute to be smaller 
than the actual cache-line size.

Me and David's concerns were more about the other architectures (core2, 
atom, "generic", etc., which do seem to be more common than P4 & NUMA) 
where the lib is still defining 128-byte cache line sizes even though 
they use 64-byte ones. Would it be worth it to have a per-architecture 
definition?

Alexandre

> Thanks,
>
> Mathieu
>
>    
>> (relatively newbie here, please be gentle :) )
>>
>> Alexandre
>>      
>
>