From mboxrd@z Thu Jan  1 00:00:00 1970
From: alexandre.montplaisir@polymtl.ca (Alexandre Montplaisir)
Date: Tue, 17 Aug 2010 16:36:30 -0400
Subject: [ltt-dev] liburcu cache line size
In-Reply-To: <20100817202717.GB22705@Krystal>
References: <4C6AD54F.4080006@polymtl.ca> <20100817185122.GA4384@Krystal>
	<4C6ADDAA.6020408@polymtl.ca> <20100817194501.GA19351@Krystal>
	<20100817195459.GC19351@Krystal> <4C6AEB51.2050004@polymtl.ca>
	<20100817202717.GB22705@Krystal>
Message-ID: <4C6AF2CE.4040000@polymtl.ca>

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
>>      
>
>