Date: Mon, 29 Oct 2012 14:48:04 +0100 From: Andre Oppermann <andre@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Jeff Roberson <jeff@freebsd.org>, attilio@freebsd.org, Florian Smeets <flo@freebsd.org>, Bruce Evans <bde@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <508E8914.7050505@freebsd.org> In-Reply-To: <20121029132605.GL73505@kib.kiev.ua> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <CAJ-FndBj8tpC_BJXs_RH8sG2TBG8yA=Lxu3-GTVT9Ap_zOCuVQ@mail.gmail.com> <CAJ-FndDnO7wjnWPV0tTu%2BUGHjsxa3YDarMxmyei3ZmjLAFvRkQ@mail.gmail.com> <201207301732.33474.jhb@freebsd.org> <CAJ-FndD5EO12xsWOAe6u0EvX00q33wxO4OivnGjzj0=T2Oe8uA@mail.gmail.com> <CAJ-FndCRg0UCThFkatp=tw7rUWWCvhsApLE=iztLpxpGBC1F9w@mail.gmail.com> <CAJ-FndBqV2uD8Th9ePtxyJwhMAPzY3AXA5cQ7HszLp=%2BfSpHTA@mail.gmail.com> <CAJ-FndDPLmkpAJeGVN2wgbhdgHYezyUV-PPvH9e-CA7Go7HG3A@mail.gmail.com> <CAJ-VmonMQgT7rGOhZ-hq%2B3R%2BSbdNfTBNHLAWW1xwicHy1cb2BQ@mail.gmail.com> <508E35E3.9020801@freebsd.org> <20121029132605.GL73505@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508E8914.7050505>