From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: [ofa-general] Re: [PATCH 01 of 12] Core of mmu notifiers Date: Tue, 22 Apr 2008 17:15:30 +0200 Message-ID: <20080422151529.GE24536@duo.random> References: <480DFC8A.8040105@cosmosbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nick Piggin , Rusty Russell , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Jack Steiner , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, Robin Holt , general@lists.openfabrics.org, Hugh Dickins , akpm@linux-foundation.org, Christoph Lameter To: Eric Dumazet Return-path: Content-Disposition: inline In-Reply-To: <480DFC8A.8040105@cosmosbay.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: general-bounces@lists.openfabrics.org Errors-To: general-bounces@lists.openfabrics.org List-Id: kvm.vger.kernel.org On Tue, Apr 22, 2008 at 04:56:10PM +0200, Eric Dumazet wrote: > Andrea Arcangeli a =E9crit : >> + >> +static int mm_lock_cmp(const void *a, const void *b) >> +{ >> + cond_resched(); >> + if ((unsigned long)*(spinlock_t **)a < >> + (unsigned long)*(spinlock_t **)b) >> + return -1; >> + else if (a =3D=3D b) >> + return 0; >> + else >> + return 1; >> +} >> + > This compare function looks unusual... > It should work, but sort() could be faster if the > if (a =3D=3D b) test had a chance to be true eventually... Hmm, are you saying my mm_lock_cmp won't return 0 if a=3D=3Db? > static int mm_lock_cmp(const void *a, const void *b) > { > unsigned long la =3D (unsigned long)*(spinlock_t **)a; > unsigned long lb =3D (unsigned long)*(spinlock_t **)b; > > cond_resched(); > if (la < lb) > return -1; > if (la > lb) > return 1; > return 0; > } If your intent is to use the assumption that there are going to be few equal entries, you should have used likely(la > lb) to signal it's rarely going to return zero or gcc is likely free to do whatever it wants with the above. Overall that function is such a slow path that this is going to be lost in the noise. My suggestion would be to defer microoptimizations like this after 1/12 will be applied to mainline. Thanks!