From owner-svn-src-user@FreeBSD.ORG Wed Oct 24 15:28:51 2012
Return-Path: <owner-svn-src-user@FreeBSD.ORG>
Delivered-To: svn-src-user@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id 06749372;
Wed, 24 Oct 2012 15:28:51 +0000 (UTC)
(envelope-from asmrookie@gmail.com)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com
[209.85.212.54])
by mx1.freebsd.org (Postfix) with ESMTP id 402348FC18;
Wed, 24 Oct 2012 15:28:50 +0000 (UTC)
Received: by mail-vb0-f54.google.com with SMTP id v11so840147vbm.13
for <multiple recipients>; Wed, 24 Oct 2012 08:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:reply-to:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
bh=G4mGrmMGpagXBVQsQE48UMVkeNXzlfKhZ8bxF54A6fE=;
b=XMCQGCnUVHci/gRz6JHBA9vfyz23OoJwIUPQn/JT27LrSiqpc7CNm/bcuHDOh1U+cz
aaqxaPRQh78GN/rxsdATOFi9IOEI4pYIUrviM8DgrxYcCX/PjgGAmg1/XssEIKdRdalO
ne7Bm3BTkXa//gxK/7ljyQ/zrB4eYz9eUBHBoWAOwZ9CAQYbQkSs3J5pOZXV3MgJowYy
Ng+6l4kz1zsTKikNv4w+XZ/Vc5NyoRIkuu/0Bwo7mvHUXASKx4APlsyw/v7KCuqZuHOW
peKO8PHysOaioUNMvkeMnJVm2OjaXsNkMGKYjNcKHOm1/+LFdQJO9FzIRkwDK9C9p9Mw
Ozgg==
MIME-Version: 1.0
Received: by 10.52.35.82 with SMTP id f18mr21599621vdj.99.1351092529625; Wed,
24 Oct 2012 08:28:49 -0700 (PDT)
Sender: asmrookie@gmail.com
Received: by 10.220.150.197 with HTTP; Wed, 24 Oct 2012 08:28:49 -0700 (PDT)
In-Reply-To: <CAJ-FndCDeB7w30PgSwOpMbWT6e+R7iQHfa8PU8Pn0NLagCiJxA@mail.gmail.com>
References: <201210221418.q9MEINkr026751@svn.freebsd.org>
<201210241005.38977.jhb@freebsd.org>
<CAJ-FndBENEuyaH+2Q+igj39tdGmsHh=3arL-Cb2GP3i9WSr_hQ@mail.gmail.com>
<201210241045.39211.jhb@freebsd.org>
<CAJ-FndC=zV+HN1wr_CnSEY93VHT--w9cYPMhH8P53y+LvBSO7g@mail.gmail.com>
<CAJ-FndCDeB7w30PgSwOpMbWT6e+R7iQHfa8PU8Pn0NLagCiJxA@mail.gmail.com>
Date: Wed, 24 Oct 2012 16:28:49 +0100
X-Google-Sender-Auth: P8LirSr1Ws4f71bZoyaChouPrd4
Message-ID: <CAJ-FndAO-75=MeGsx7dtcbfYurpfeANa71NeRipyg0Ekib+d5Q@mail.gmail.com>
Subject: Re: svn commit: r241889 - in user/andre/tcp_workqueue/sys: arm/arm
cddl/compat/opensolaris/kern cddl/contrib/opensolaris/uts/common/dtrace
cddl/contrib/opensolaris/uts/common/fs/zfs ddb dev/acpica dev/...
From: Attilio Rao <attilio@freebsd.org>
To: John Baldwin <jhb@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Cc: mdf@freebsd.org, src-committers@freebsd.org,
Andre Oppermann <andre@freebsd.org>, Bruce Evans <brde@optusnet.com.au>,
svn-src-user@freebsd.org
X-BeenThere: svn-src-user@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: attilio@FreeBSD.org
List-Id: "SVN commit messages for the experimental " user"
src tree" <svn-src-user.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-user>,
<mailto:svn-src-user-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-user>
List-Post: <mailto:svn-src-user@freebsd.org>
List-Help: <mailto:svn-src-user-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>,
<mailto:svn-src-user-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 15:28:51 -0000
On Wed, Oct 24, 2012 at 4:24 PM, Attilio Rao <attilio@freebsd.org> wrote:
> On Wed, Oct 24, 2012 at 4:09 PM, Attilio Rao <attilio@freebsd.org> wrote:
>> On Wed, Oct 24, 2012 at 3:45 PM, John Baldwin <jhb@freebsd.org> wrote:
>>> On Wednesday, October 24, 2012 10:34:34 am Attilio Rao wrote:
>>>> On Wed, Oct 24, 2012 at 3:05 PM, John Baldwin <jhb@freebsd.org> wrote:
>>>> > On Tuesday, October 23, 2012 7:20:04 pm Andre Oppermann wrote:
>>>> >> On 24.10.2012 00:15, mdf@FreeBSD.org wrote:
>>>> >> > On Tue, Oct 23, 2012 at 7:41 AM, Andre Oppermann <andre@freebsd.org>
>>> wrote:
>>>> >> >> Struct mtx and MTX_SYSINIT always occur as pair next to each other.
>>>> >> >
>>>> >> > That doesn't matter. Language basics like variable definitions should
>>>> >> > not be obscured by macros. It either takes longer to figure out what
>>>> >> > a variable is (because one needs to look up the definition of the
>>>> >> > macro) or makes it almost impossible (because now e.g. cscope doesn't
>>>> >> > know this is a variable definition.
>>>> >>
>>>> >> Sigh, cscope doesn't expand macros?
>>>> >>
>>>> >> Is there a way to do the cache line alignment in a sane way without
>>>> >> littering __aligned(CACHE_LINE_SIZE) all over the place?
>>>> >
>>>> > I was hoping to do something with an anonymous union or some such like:
>>>> >
>>>> > union mtx_aligned {
>>>> > struct mtx;
>>>> > char[roundup2(sizeof(struct mtx), CACHE_LINE_SIZE)];
>>>> > }
>>>> >
>>>> > I don't know if there is a useful way to define an 'aligned mutex' type
>>>> > that will transparently map to a 'struct mtx', e.g.:
>>>> >
>>>> > typedef struct mtx __aligned(CACHE_LINE_SIZE) aligned_mtx_t;
>>>>
>>>> Unfortunately that doesn't work as I've verified with alc@ few months ago.
>>>> The __aligned() attribute only works with structures definition, not
>>>> objects declaration.
>>>
>>> Are you saying that the typedef doesn't (I expect it doesn't), or that this
>>> doesn't:
>>>
>>> struct mtx foo __aligned(CACHE_LINE_SIZE);
>>
>> I meant to say that such notation won't address the padding issue
>> which is as import as the alignment. Infact, for sensitive locks,
>> having just an aligned object is not really useful if the cacheline
>> gets shared.
>> In the end you will need to use explicit padding or use __aligned in
>> the struct definition, which cannot be used as a general pattern.
>
> The quickest way I see this can be made general is to have a specific
> struct defined in sys/_mutex.h like that
>
> struct mtx_unshare {
> struct mtx lock;
> char _pad[CACHE_LINE_SIZE - sizeof(struct mtx)];
> } __aligned(CACHE_LINE_SIZE);
This can be however be dangerous for the KBI because I'm not sure we
assume the same CACHE_LINE_SIZE for every family processor within the
same architectures. I'm sure x86 supports at least 2 different
cacheline sizes, even if I admit I cannot recall (and cannot check
right now) if we actually differentiate them in the end. However, if
we want to support such mechanism and changing CACHE_LINE_SIZE, likely
struct mtx_unshare cannot be used proficiently in modules (but that is
however true with current handworking too, so it is not any worse than
what we can get today as well).
Attilio
--
Peace can only be achieved by understanding - A. Einstein