From owner-svn-src-projects@FreeBSD.ORG Mon Oct 29 07:53:11 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2D95993 for ; Mon, 29 Oct 2012 07:53:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1C08FC16 for ; Mon, 29 Oct 2012 07:53:10 +0000 (UTC) Received: (qmail 95318 invoked from network); 29 Oct 2012 09:30:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Oct 2012 09:30:07 -0000 Message-ID: <508E35E3.9020801@freebsd.org> Date: Mon, 29 Oct 2012 08:53:07 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern References: <201207301350.q6UDobCI099069@svn.freebsd.org> <201207301732.33474.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, John Baldwin , Jeff Roberson , attilio@freebsd.org, Florian Smeets , Bruce Evans , svn-src-projects@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:53:11 -0000 On 29.10.2012 03:25, Adrian Chadd wrote: > So colour me a bit silly, but why didn't you use an atomic here for > that single variable, rather than a memory barrier alone? Because sched_pin() can only be used within a critical section and thus guarantees that we stay on the same CPU. So we don't have to worry about full SMP visibility and preventing just the compiler from reordering or register caching the value. The atomic functions do a full bus lock cycle and a CPU pipeline flush (in most cases) to make sure that the new value is seen on all CPU's at the same time. On SMP architectures and shared data structures you have to worry about three things: - compiler reordering (instruction optimizations) - cpu pipelines - memory and cache coherency To be honest it takes some time to understand the different behaviors and then to be able to reason about it. There is quite some nice and dense literature out there about atomics. Googling turns up the important ones. > I feel slightly nitpicky about it, but this stuff rubs me up slightly > the wrong way, same as the "don't worry about using atomics for 32 bit > set/reads, as those are guaranteed to be atomic on all of the > platforms we use" done what, last year or so. Well, we have to have a baseline somewhere. Many architectures don't even have atomics for less than 32 bits. -- Andre