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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
