From owner-svn-src-projects@FreeBSD.ORG Mon Oct 29 13:48:09 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 55E2F7D8 for ; Mon, 29 Oct 2012 13:48:09 +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 868338FC18 for ; Mon, 29 Oct 2012 13:48:08 +0000 (UTC) Received: (qmail 40012 invoked from network); 29 Oct 2012 15:25:02 -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 15:25:02 -0000 Message-ID: <508E8914.7050505@freebsd.org> Date: Mon, 29 Oct 2012 14:48:04 +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: Konstantin Belousov Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern References: <201207301350.q6UDobCI099069@svn.freebsd.org> <201207301732.33474.jhb@freebsd.org> <508E35E3.9020801@freebsd.org> <20121029132605.GL73505@kib.kiev.ua> In-Reply-To: <20121029132605.GL73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , 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 13:48:09 -0000 On 29.10.2012 14:26, Konstantin Belousov wrote: > On Mon, Oct 29, 2012 at 08:53:07AM +0100, Andre Oppermann wrote: >> 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. > > This is wrong, both for preassumption ('sched_pin() can only be used > within a critical section') and for the conclusion. sched_pin() does > not require the containing critical section for use. > > sched_pin() is a thread-local operation. This is why we should only > worry about local reordering, since mi_switch() must be executed > by current processor to switch the current thread. I wasn't aware of these intimate dependencies and constrains. Thanks for explaining it. The lack of SMP visibility was the important part wrt. atomic ops. -- Andre