From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935046Ab0HFUDI (ORCPT ); Fri, 6 Aug 2010 16:03:08 -0400 Received: from claw.goop.org ([74.207.240.146]:56846 "EHLO claw.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934215Ab0HFUDC (ORCPT ); Fri, 6 Aug 2010 16:03:02 -0400 Message-ID: <4C5C6A74.1050106@goop.org> Date: Fri, 06 Aug 2010 13:03:00 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: "H. Peter Anvin" CC: Konrad Rzeszutek Wilk , Linux Kernel Mailing List , Nick Piggin , Peter Zijlstra , Xen-devel , Avi Kivity , Jan Beulich Subject: Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock References: <20100720153845.GA9122@phenom.dumpdata.com> <4C45CC02.7030603@goop.org> <4C5C4AAB.3000606@zytor.com> In-Reply-To: <4C5C4AAB.3000606@zytor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/06/2010 10:47 AM, H. Peter Anvin wrote: > On 07/20/2010 09:17 AM, Jeremy Fitzhardinge wrote: >> "volatile" would be a compiler barrier, but it has no direct effect on, >> or relevence to, the CPU. It just cares about the LOCK_PREFIX. The >> "memory" clobber is probably unnecessary as well, since the constraints >> already tell the compiler the most important information. We can add >> barriers separately as needed. >> > You absolutely need volatile, since otherwise you're permitting the > compiler to split, re-execute or even drop the code. Anything else > might work, by accident, but it's not clean. I don't think so in this case. The instructions in question are basically lock->waiters++/--; the only reason they need to be asm is that they're locked. But I'm not relying on them for any kind of compiler or cpu ordering or barrier. Where ordering is important, I have explicit barrier()s to enforce it. J From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock Date: Fri, 06 Aug 2010 13:03:00 -0700 Message-ID: <4C5C6A74.1050106@goop.org> References: <20100720153845.GA9122@phenom.dumpdata.com> <4C45CC02.7030603@goop.org> <4C5C4AAB.3000606@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C5C4AAB.3000606@zytor.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "H. Peter Anvin" Cc: Nick Piggin , Xen-devel , Konrad Rzeszutek Wilk , Peter Zijlstra , Linux Kernel Mailing List , Jan Beulich , Avi Kivity List-Id: xen-devel@lists.xenproject.org On 08/06/2010 10:47 AM, H. Peter Anvin wrote: > On 07/20/2010 09:17 AM, Jeremy Fitzhardinge wrote: >> "volatile" would be a compiler barrier, but it has no direct effect on, >> or relevence to, the CPU. It just cares about the LOCK_PREFIX. The >> "memory" clobber is probably unnecessary as well, since the constraints >> already tell the compiler the most important information. We can add >> barriers separately as needed. >> > You absolutely need volatile, since otherwise you're permitting the > compiler to split, re-execute or even drop the code. Anything else > might work, by accident, but it's not clean. I don't think so in this case. The instructions in question are basically lock->waiters++/--; the only reason they need to be asm is that they're locked. But I'm not relying on them for any kind of compiler or cpu ordering or barrier. Where ordering is important, I have explicit barrier()s to enforce it. J