From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Diestelhorst Subject: Re: [Xen-devel] [PATCH 00/10] [PATCH RFC V2] Paravirtualized ticketlocks Date: Thu, 6 Oct 2011 16:04:13 +0200 Message-ID: <2707952.s3VYcmPHUN@chlor> References: <201109282008.17722.stephan.diestelhorst@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Cc: Jeremy Fitzhardinge , "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 Wednesday 28 September 2011, 14:49:56 Linus Torvalds wrote: > On Wed, Sep 28, 2011 at 11:08 AM, Stephan Diestelhorst > wrote: > > > > I must have missed the part when this turned into the propose-the- > > craziest-way-that-this-still-works.contest :) > > So doing it just with the "lock addb" probably works fine, but I have > to say that I personally shudder at the "surround the locked addb by > reads from the word, in order to approximate an atomic read of the > upper bits". > > Because what you get is not really an "atomic read of the upper bits", > it's a "ok, we'll get the worst case of somebody modifying the upper > bits at the same time". > > Which certainly should *work*, but from a conceptual standpoint, isn't > it just *much* nicer to say "we actually know *exactly* what the upper > bits were". Well, we really do NOT want atomicity here. What we really rather want is sequentiality: free the lock, make the update visible, and THEN check if someone has gone sleeping on it. Atomicity only conveniently enforces that the three do not happen in a different order (with the store becoming visible after the checking load). This does not have to be atomic, since spurious wakeups are not a problem, in particular not with the FIFO-ness of ticket locks. For that the fence, additional atomic etc. would be IMHO much cleaner than the crazy overflow logic. > 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". Fair enough :) Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@amd.com Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551