From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755186AbbDJJNA (ORCPT ); Fri, 10 Apr 2015 05:13:00 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:38696 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753326AbbDJJM5 (ORCPT ); Fri, 10 Apr 2015 05:12:57 -0400 Date: Fri, 10 Apr 2015 11:12:53 +0200 From: Ingo Molnar To: "Paul E. McKenney" Cc: Linus Torvalds , Jason Low , Peter Zijlstra , Davidlohr Bueso , Tim Chen , Aswin Chandramouleeswaran , LKML Subject: Re: [PATCH] mutex: Speed up mutex_spin_on_owner() by not taking the RCU lock Message-ID: <20150410091252.GA27630@gmail.com> References: <1428521960-5268-3-git-send-email-jason.low2@hp.com> <20150409053725.GB13871@gmail.com> <1428561611.3506.78.camel@j-VirtualBox> <20150409075311.GA4645@gmail.com> <20150409175652.GI6464@linux.vnet.ibm.com> <20150409183926.GM6464@linux.vnet.ibm.com> <20150410090051.GA28549@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150410090051.GA28549@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Ingo Molnar wrote: > 0000000000000030 : > 30: 48 3b 37 cmp (%rdi),%rsi > 33: 48 8d 4e 28 lea 0x28(%rsi),%rcx > 37: 75 4e jne 87 > 39: 55 push %rbp > 3a: 45 31 c0 xor %r8d,%r8d > 3d: 65 4c 8b 0c 25 00 00 mov %gs:0x0,%r9 > 44: 00 00 > 46: 48 89 e5 mov %rsp,%rbp > 49: 48 83 ec 10 sub $0x10,%rsp > 4d: eb 08 jmp 57 > 4f: 90 nop > 50: f3 90 pause > 52: 48 3b 37 cmp (%rdi),%rsi > 55: 75 29 jne 80 > 57: 44 89 c0 mov %r8d,%eax > 5a: 90 nop > 5b: 90 nop > 5c: 90 nop > 5d: 8b 11 mov (%rcx),%edx > 5f: 90 nop > 60: 90 nop > 61: 90 nop Yeah, so what I missed here are those nops: placeholders for the STAC/CLAC instructions on x86... and this is what Linus mentioned about the clac() overhead. But this could be solved I think: by adding a copy_from_kernel_inatomic() primitive which simply leaves out the STAC/CLAC sequence: as these are always guaranteed to be kernel addresses, the SMAP fault should not be generated. Thanks, Ingo