From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Wed, 28 Sep 2011 12:06:36 -0700 Message-ID: <4E83703C.2010907@goop.org> References: <4E835851.7070502@zytor.com> <4E835E50.2020307@goop.org> <201109282008.17722.stephan.diestelhorst@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stephan Diestelhorst , "H. Peter Anvin" , Jan Beulich , Jeremy Fitzhardinge , Ingo Molnar , Andi Kleen , Peter Zijlstra , Nick Piggin , the arch/x86 maintainers , "xen-devel@lists.xensource.com" , Avi Kivity , Marcelo Tosatti , KVM , Linux Kernel Mailing List To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 09/28/2011 11:49 AM, Linus Torvalds wrote: > But I don't care all *that* deeply. I do agree that the xaddw trick is > pretty tricky. I just happen to think that it's actually *less* tricky > than "read the upper bits separately and depend on subtle ordering > issues with another writer that happens at the same time on another > CPU". > > So I can live with either form - as long as it works. I think it might > be easier to argue that the xaddw is guaranteed to work, because all > values at all points are unarguably atomic (yeah, we read the lower > bits nonatomically, but as the owner of the lock we know that nobody > else can write them). Exactly. I just did a locked add variant, and while the code looks a little simpler, it definitely has more actual complexity to analyze. J