From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex Date: Mon, 21 Jul 2014 23:47:02 +0200 (CEST) Message-ID: 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> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Andy Lutomirski Cc: Peter Zijlstra , Darren Hart , 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 List-Id: linux-api@vger.kernel.org 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. Thanks, tglx