From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760000AbYFFPCr (ORCPT ); Fri, 6 Jun 2008 11:02:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757314AbYFFPCi (ORCPT ); Fri, 6 Jun 2008 11:02:38 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41949 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751452AbYFFPCh (ORCPT ); Fri, 6 Jun 2008 11:02:37 -0400 Date: Fri, 6 Jun 2008 08:01:08 -0700 (PDT) From: Linus Torvalds To: Nick Piggin cc: Ingo Molnar , David Howells , Ulrich Drepper , Linux Kernel Mailing List , Andrew Morton Subject: Re: [PATCH 0/3] 64-bit futexes: Intro In-Reply-To: <20080606115305.GA20345@wotan.suse.de> Message-ID: References: <4840CE51.9060109@redhat.com> <4840D63F.2090407@redhat.com> <20080602185433.GB4081@elte.hu> <20080606012749.GA12187@wotan.suse.de> <20080606115305.GA20345@wotan.suse.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 6 Jun 2008, Nick Piggin wrote: > > Well... a single lock is only going to be so scalable. I don't see how > it could be done really significantly better? My worry is that I did something wrong in the slowpath, and that there is some thundering-herd-wakeup kind of thing that makes that much slower than it should be. The slow path doesn't much matter from the angle of counting individual cycles, but it still matters very much from a bigger picture. Does it have bad behavior where we wake up a thousand readers, but then a writer gets to come in first and all the readers have to go to sleep again? That's one thing I tried to avoid in the second version (the "Another approch" commit) where a read-wakeup actually moves the readers from the pending count to the final count - both to get more fairness (which can be _bad_ for performance), but also because I think it can avoid pathological cases (reader starvation and unnecessary futex wakeup). Linus