WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction ab

To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 18 Jun 2008 17:37:27 -0700
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, benh@xxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Hugh Dickins <hugh@xxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Delivery-date: Wed, 18 Jun 2008 17:38:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.LFD.1.10.0806181723400.2907@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <b020e42384197b824320.1213615800@localhost> <1213831403.8011.24.camel@pasglop> <4859A149.9090004@xxxxxxxx> <4859A528.1010107@xxxxxxxx> <alpine.LFD.1.10.0806181723400.2907@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080501)
Linus Torvalds wrote:
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
Along the lines of:

Hell no. There's a reason we have a special set_wrprotect() thing. We can do it more efficiently on native hardware by just clearing the bit atomically. No need to do the cmpxchg games.

It's not cmpxchg, just xchg.
In other words, is:

        lock btr $_PAGE_BIT_RW, (%rbx)

much cheaper than

        mov     $0, %rax
        xchg    %rax, (%rbx)
        and     $~_PAGE_RW, %rax
        mov     %rax, (%rbx)

?

It's the same number of locked RMW operations, so aside from being a few instructions longer, I think it would be much the same.

I guess the correct answer is "lmbench".

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>