From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Tue, 17 Aug 2010 16:27:17 -0400
Subject: [ltt-dev] liburcu cache line size
In-Reply-To: <4C6AEB51.2050004@polymtl.ca>
References: <4C6AD54F.4080006@polymtl.ca> <20100817185122.GA4384@Krystal>
	<4C6ADDAA.6020408@polymtl.ca> <20100817194501.GA19351@Krystal>
	<20100817195459.GC19351@Krystal> <4C6AEB51.2050004@polymtl.ca>
Message-ID: <20100817202717.GB22705@Krystal>

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

Thanks,

Mathieu

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


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