Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2012 11:56:31 -0700
From:      Jim Harris <jim.harris@gmail.com>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r242014 - head/sys/kern
Message-ID:  <CAJP=Hc9XmvfW3MrDjvK15OAx1fyfjPk%2BEhqHUOzoEpChu5imtg@mail.gmail.com>
In-Reply-To: <CAJ-VmonpdJ445hXVaoHqFgS0v7QRwqHWodQrVHm2CN9T661www@mail.gmail.com>
References:  <201210241836.q9OIafqo073002@svn.freebsd.org> <CAJ-VmonpdJ445hXVaoHqFgS0v7QRwqHWodQrVHm2CN9T661www@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 24, 2012 at 11:41 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 24 October 2012 11:36, Jim Harris <jimharris@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.

>
>
> Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc9XmvfW3MrDjvK15OAx1fyfjPk%2BEhqHUOzoEpChu5imtg>