From owner-svn-src-head@FreeBSD.ORG Mon Jun 24 08:11:06 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DFB6454; Mon, 24 Jun 2013 08:11:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 729CF15EF; Mon, 24 Jun 2013 08:11:04 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5O8Avlw049388; Mon, 24 Jun 2013 12:10:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5O8AuTA049387; Mon, 24 Jun 2013 12:10:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 24 Jun 2013 12:10:56 +0400 From: Gleb Smirnoff To: Konstantin Belousov Subject: Re: svn commit: r252032 - head/sys/amd64/include Message-ID: <20130624081056.GD1214@FreeBSD.org> References: <20130621065839.J916@besplex.bde.org> <20130621081116.E1151@besplex.bde.org> <20130621090207.F1318@besplex.bde.org> <20130621064901.GS1214@FreeBSD.org> <20130621184140.G848@besplex.bde.org> <20130621135427.GA1214@FreeBSD.org> <20130622110352.J2033@besplex.bde.org> <20130622124832.S2347@besplex.bde.org> <20130622174921.I3112@besplex.bde.org> <20130623073343.GY91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130623073343.GY91021@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 24 Jun 2013 08:11:06 -0000 On Sun, Jun 23, 2013 at 10:33:43AM +0300, Konstantin Belousov wrote: K> On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: K> > So the i386 version be simply "addl; adcl" to memory. Each store in K> > this is atomic at the per-CPU level. If there is no carry, then the K> > separate stores are equivalent to adding separate nonnegative values and K> > the counter value is valid at all times. If there is carry, then the K> > separate stores are equivalent to adding a negative value followed by K> > a larger positive value. The counter transiently goes backwards, but K> > no information is lost and the counter is eventually set to the correct K> > forward-going value. K> K> This is quite interesting idea, but I still did not decided if it K> acceptable. The issue is that we could add the carry to the other K> processor counter, if the preemption kicks in at right time between K> two instructions. I did not found any argument why would it be K> wrong, the races for fetch operation seems to be the same with either K> local update method. This would be wrong since update isn't locked. Thus, if we are put on other CPU between two instructions, and in second instruction updating another CPU counter simultaneously with the original CPU we were on, then we are losing an update. Yes, the probability of such event is extremely low, but still possible. The idea on counter(9) is that although fetching might be not precise, the internal value of a counter is consistent and doesn't lose even a single update. This would allow later to use counter(9) as a cheap reference counter. -- Totus tuus, Glebius.