svn commit: r242014 - head/sys/kern

[Jim Harris]

On Wed, Oct 24, 2012 at 12:08 PM, Attilio Rao <attilio at freebsd.org> wrote:
> On Wed, Oct 24, 2012 at 7:56 PM, Jim Harris <jim.harris at gmail.com> wrote:
>> On Wed, Oct 24, 2012 at 11:41 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>>> On 24 October 2012 11:36, Jim Harris <jimharris at freebsd.org> wrote:
>>>
>>>>   Pad tdq_lock to avoid false sharing with tdq_load and tdq_cpu_idle.
>>>
>>> Ok, but..
>>>
>>>
>>>>         struct mtx      tdq_lock;               /* run queue lock. */
>>>> +       char            pad[64 - sizeof(struct mtx)];
>>>
>>> .. don't we have an existing compile time macro for the cache line
>>> size, which can be used here?
>>
>> Yes, but I didn't use it for a couple of reasons:
>>
>> 1) struct tdq itself is currently using __aligned(64), so I wanted to
>> keep it consistent.
>> 2) CACHE_LINE_SIZE is currently defined as 128 on x86, due to
>> NetBurst-based processors having 128-byte cache sectors a while back.
>> I had planned to start a separate thread on arch@ about this today on
>> whether this was still appropriate.
>
> While you may want to bring CACHE_LINE_SIZE to 64, code in sched_ule
> should still use CACHE_LINE_SIZE, as MI code cannot make assumption on
> cache line sizes for all the architectures.
> Your reasons for using 64 are valid, but a further next step to
> cleanup CACHE_LINE_SIZE and then use it properly in sched_ule are due
> IMHO.

Yes - I agree.  I wanted to get some sort of consensus on using
CACHE_LINE_SIZE=64 on x86 before moving forward with this change.

> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein