From owner-freebsd-arch@FreeBSD.ORG  Tue Oct 28 14:25:25 2014
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id C00D9FA9;
 Tue, 28 Oct 2014 14:25:25 +0000 (UTC)
Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198])
 by mx1.freebsd.org (Postfix) with ESMTP id A2236252;
 Tue, 28 Oct 2014 14:25:25 +0000 (UTC)
Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231])
 by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 0E9225C692;
 Tue, 28 Oct 2014 14:25:16 +0000 (UTC)
Date: Tue, 28 Oct 2014 14:25:10 +0000
From: Andrew Turner <andrew@fubar.geek.nz>
To: Attilio Rao <attilio@freebsd.org>
Subject: Re: atomic ops
Message-ID: <20141028142510.10a9d3cb@bender.lan>
In-Reply-To: <CAJ-FndCWZt7YwFswt70QvbXA5c8Q_cYME2m3OwHTjCv8Nu3s=Q@mail.gmail.com>
References: <20141028025222.GA19223@dft-labs.eu>
 <CAJ-FndCWZt7YwFswt70QvbXA5c8Q_cYME2m3OwHTjCv8Nu3s=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>,
 Adrian Chadd <adrian@freebsd.org>, Mateusz Guzik <mjguzik@gmail.com>,
 Konstantin Belousov <kib@freebsd.org>, Alan Cox <alc@rice.edu>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 14:25:25 -0000

On Tue, 28 Oct 2014 14:18:41 +0100
Attilio Rao <attilio@freebsd.org> wrote:

> On Tue, Oct 28, 2014 at 3:52 AM, Mateusz Guzik <mjguzik@gmail.com>
> wrote:
> > As was mentioned sometime ago, our situation related to atomic ops
> > is not ideal.
> >
> > atomic_load_acq_* and atomic_store_rel_* (at least on amd64) provide
> > full memory barriers, which is stronger than needed.
> >
> > Moreover, load is implemented as lock cmpchg on var address, so it
> > is addditionally slower especially when cpus compete.
> 
> I already explained this once privately: fully memory barriers is not
> stronger than needed.
> FreeBSD has a different semantic than Linux. We historically enforce a
> full barrier on _acq() and _rel() rather then just a read and write
> barrier, hence we need a different implementation than Linux.
> There is code that relies on this property, like the locking
> primitives (release a mutex, for instance).

On 32-bit ARM prior to ARMv8 (i.e. all chips we currently support)
there are only full barriers. On both 32 and 64-bit ARMv8 ARM has added
support for load-acquire and store-release atomic instructions. For the
use in atomic instructions we can assume these only operate of the
address passed to them.

It is unlikely we will use them in the 32-bit port however I would like
to know the expected semantics of these atomic functions to make sure
we get them correct in the arm64 port. I have been advised by one of
the ARM Linux kernel maintainers on the problems they have found using
these instructions but have yet to determine what our atomic functions
guarantee.

Andrew