Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754305AbaGUWl5 (ORCPT ); Mon, 21 Jul 2014 18:41:57 -0400 Received: from mga09.intel.com ([134.134.136.24]:1770 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753649AbaGUWlx (ORCPT ); Mon, 21 Jul 2014 18:41:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,705,1400050800"; d="scan'208";a="576682134" User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Mon, 21 Jul 2014 15:41:42 -0700 Subject: Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex From: Darren Hart To: Thomas Gleixner , Andy Lutomirski CC: Peter Zijlstra , Andi Kleen , Waiman Long , Ingo Molnar , Davidlohr Bueso , Heiko Carstens , "linux-kernel@vger.kernel.org" , Linux API , "linux-doc@vger.kernel.org" , Jason Low , Scott J Norton Message-ID: Thread-Topic: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex References: <1405956271-34339-1-git-send-email-Waiman.Long@hp.com> <8761iq3bp3.fsf@tassilo.jf.intel.com> <871tte3bjw.fsf@tassilo.jf.intel.com> <20140721212740.GS3935@laptop> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/21/14, 14:47, "Thomas Gleixner" wrote: >On Mon, 21 Jul 2014, Andy Lutomirski wrote: >> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra >>wrote: >> > All this is predicated on the fact that syscalls are 'expensive'. >> > Weren't syscalls only 100s of cycles? All this bitmap mucking is far >> > more expensive due to cacheline misses, which due to the size of the >> > things is almost guaranteed. >> >> 120 - 300 cycles for me, unless tracing happens, and I'm working on >> reducing the incidence of tracing. > >So it's a non issue indeed and definitely not worth the trouble of >that extra storage, the scheduler overhead, etc. > >Summary: Once you can't take it atomically in user space, you've lost > anyway. And we are better off to do the magic spinning in > kernel where we have all the information accessible already. And we have such an implementation with the FUTEX_LOCK_ADAPTIVE code we discussed back in Oct 2010 (purely kernel, no VDSO), updated with some of your and other's comments: http://git.infradead.org/users/dvhart/linux.git/shortlog/refs/heads/futex/f utex-lock/v7 I can work on forward porting this series to current mainline (post recent security fixes) and cleaning up the commentary and such if people are interested in seeing this implementation (based on Peter Z's spinning mutex work iirc) resurrected... -- Darren Hart Open Source Technology Center darren.hart@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/