From owner-svn-src-head@FreeBSD.ORG Mon Jun 24 14:22:01 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 935BED18; Mon, 24 Jun 2013 14:22:01 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 365BC1A7B; Mon, 24 Jun 2013 14:22:01 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id ta17so10990366obb.36 for ; Mon, 24 Jun 2013 07:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=d06nQRx0Qd21B2EhpT2rFq27agrqPWxobPKKk1N52EI=; b=mAKfP2mCszmcdM25a1yxOFLgfFRwFvNH1HxxnntgTf/twbkRJTzjGrvvrczZKbl5M6 V+CGBmwQqSdIn0NVhNSSzGanftIEOcpgstoGv2/aYmUSwUU7TGEZDg9w6NgGPYe7c3hr f2/5G9A6WduQBKbqsk8RRSn4sNHvmXfrYMeuxl34XpXV7Z4vvwiN6aqprkb5rGOdCP87 fr7UCVGfIHbxTj4yZ2oOzhl1QZ4V3Wl0iqGWUZPwWP7SBzY3jVcvRIrFNe3UlHgF6L/Z NBfcuMi52gUuCTw4A5VqxQ8usKUtHRz/sJtsvH4ryi99UwZMH+7cu7WZrwSIPMPQoH8k s2aw== MIME-Version: 1.0 X-Received: by 10.60.137.163 with SMTP id qj3mr11388727oeb.84.1372083720651; Mon, 24 Jun 2013 07:22:00 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.162.65 with HTTP; Mon, 24 Jun 2013 07:22:00 -0700 (PDT) In-Reply-To: <20130624211428.O2235@besplex.bde.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> <20130624081056.GD1214@FreeBSD.org> <20130624211428.O2235@besplex.bde.org> Date: Mon, 24 Jun 2013 07:22:00 -0700 X-Google-Sender-Auth: klwJfJs8BjXqSm2wCxtCxq_GBGk Message-ID: Subject: Re: svn commit: r252032 - head/sys/amd64/include From: mdf@FreeBSD.org To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Gleb Smirnoff , "src-committers@freebsd.org" 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 14:22:01 -0000 [snipping everything about counter64, atomic ops, cycles, etc.] I wonder if the idea explained in this paper: http://static.usenix.org/event/usenix03/tech/freenix03/full_papers/mcgarry/mcgarry_html/ Which seems to be used in FreeBSD for some ARM atomics: http://svnweb.freebsd.org/base/head/sys/arm/include/atomic.h?view=annotate , look for ARM_RAS_START would be more efficient. To summarize: one marks a section of code such that if a thread is interrupted during the code it restarts at the beginning instead of where it was interrupted. This has been used to implement atomic increment on some hardware without the necessary instructions. Here it could be used to implement atomic increment on the per-cpu counter without the overhead of an atomic instruction. It's multiple stores to mark the section of code doing the increment, but they're all per-cpu or per thread. That may be cheaper than an atomic increment, at least on 32-bit platforms that are doing an atomic 64-bit increment. I haven't benchmarked this (ENOTIME, plus I'm on vacation right now), but using restartable sections requires three stores (add an item to a linked list, 64-bit increment for the counter, remove an item from a linked list). Some of the penalty is payed in the context switch code, which has to check if the instruction pointer is in one of these critical sections. I haven't checked to see if this code is enabled on all architectures or just ARM. But if context switches are less frequent than counter increments in the networking code, it's still a win for most uses. Thanks, matthew