Messages in this thread | | | Date | Tue, 22 Apr 2008 17:15:30 +0200 | From | Andrea Arcangeli <> | Subject | Re: [PATCH 01 of 12] Core of mmu notifiers |
| |
On Tue, Apr 22, 2008 at 04:56:10PM +0200, Eric Dumazet wrote: > Andrea Arcangeli a écrit : >> + >> +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 == b) >> + return 0; >> + else >> + return 1; >> +} >> + > This compare function looks unusual... > It should work, but sort() could be faster if the > if (a == b) test had a chance to be true eventually...
Hmm, are you saying my mm_lock_cmp won't return 0 if a==b?
> static int mm_lock_cmp(const void *a, const void *b) > { > unsigned long la = (unsigned long)*(spinlock_t **)a; > unsigned long lb = (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!
-- 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/
| |