Re: [PATCH 2.6.20-rc4 0/4] futexes functionalities and improvements
From: Pierre Peiffer
Date: Fri Jan 12 2007 - 02:55:20 EST
Andrew Morton a écrit :
> OK. Unfortunately patches 2-4 don't apply without #1 present and the fix
> is not immediately obvious, so we'll need a respin+retest, please.
Ok, I'll provide updated patches for -mm ASAP.
On Thu, 11 Jan 2007 09:47:28 -0800
Ulrich Drepper <drepper@xxxxxxxxxx> wrote:
if the patches allow this, I'd like to see parts 2, 3, and 4 to be in
-mm ASAP. Especially the 64-bit variants are urgently needed. Just
hold off adding the plist use, I am still not convinced that
unconditional use is a good thing, especially with one single global list.
Just to avoid any misunderstanding (I (really) understand your point about
performance issue), but:
* the problem I mention about several futexes hashed on the same key, and thus
with all potential waiters listed on the same list, is _not_ a new problem which
comes with this patch: it already exists today, with simple list.
* the measures of performance done with pthread_broadcast (and thus with
futex_requeue) is a good choice (well, may be not realistic, when considering
real applications (*)) to put in evidence the performance impact, rather than
threads making FUTEX_WAIT/FUTEX_WAKE: what is expensive with plist is the
plist_add operation (which occurs in FUTEX_WAIT), not plist_del (which occurs
during FUTEX_WAKE => thus, no big impact should be noticed here). Any measure
will be difficult to do with only FUTEX_WAIT/WAKE.
=> futex_requeue does as many plist_del/plist_add operations as the number of
threads waiting (minus 1), and thus has a direct impact on the time needed to
wake everybody (or to wake the first thread to be more precise).
(*) I'll try the volano bench, if I have time.
--
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/