From owner-svn-src-head@FreeBSD.ORG Thu Sep 13 20:11:27 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A891065679; Thu, 13 Sep 2012 20:11:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD6228FC1B; Thu, 13 Sep 2012 20:11:26 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A93CB93B; Thu, 13 Sep 2012 16:11:26 -0400 (EDT) From: John Baldwin To: Bryan Venteicher Date: Thu, 13 Sep 2012 14:56:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <651175615.1815.1347554442005.JavaMail.root@daemoninthecloset.org> In-Reply-To: <651175615.1815.1347554442005.JavaMail.root@daemoninthecloset.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201209131456.03422.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Sep 2012 16:11:26 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Peter Grehan Subject: Re: svn commit: r240427 - head/sys/dev/virtio X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 20:11:27 -0000 On Thursday, September 13, 2012 12:40:42 pm Bryan Venteicher wrote: > > Would it be possible to use atomic_load/store() instead of direct > > memory barriers? For example: > > > > I've been sitting on a (lightly tested) patch [1] for awhile that > does just that, but am not very happy with it. A lot of the fields > are 16-bit, which not all architectures have atomic(9) support for. > And I think the atomic(9) behavior on UP kernels does not provide > the same guarantees as on an SMP kernel (could have an UP kernel > on an SMP host). That is the one thing I was worried about (the fields being defined to be 16-bit). I presume that is required by the virtio de facto standard? Shame we can't clue-by-four people putting 16-bit fields in these sort of things. :-P > I also found myself wanting an atomic_load_rel_*() type function. That would be odd I think. _rel barriers only affect stores, so there would be no defined ordering between the load and the subsequent stores. (With our current definitions of _acq and _rel.) If you need a full fence for some reason, than a plain mb() may be the best thing in that case. -- John Baldwin