[ltt-dev] liburcu cache line size

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> 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?

It becomes a mess trying to have defines for each sub-architecture when
not clearly needed. In this case, we just waste a few bytes of memory
here and there, nothing to call home about, really.

We always have to think that these are usually packaged by distros,
which have to use defaults that will work well on a wide set of
machines.

Thanks,

Mathieu

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

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com