Re: [RFC][PATCH RT 0/2] futex priority based wakeup

From: Pierre Peiffer
Date: Fri May 12 2006 - 09:30:51 EST


Hi,

Just few comments for my understanding:

Ingo Molnar a écrit :
* Sébastien Dugué <sebastien.dugue@xxxxxxxx> wrote:

in the current futex implementation, tasks are woken up in FIFO order, (i.e. in the order they were put to sleep). For realtime systems needing system wide strict realtime priority scheduling, tasks should be woken up in priority order.

This patchset achieves this by changing the futex hash bucket list into a plist. Tasks waiting on a futex are enqueued in this plist based on their priority so that they can be woken up in priority order.

hm, i dont think this is enough. Basically, waking up in priority order is just the (easier) half of the story - what you want is to also propagate priorities when you block. We provided a complete solution via the PI-futex patchset (currently included in -mm).

In other words: as long as locking primitives go, i dont think real-time applications should use wakeup-priority-ordered futexes, they should use the real thing, PI futexes.

In fact, I agree with that for a lock (pthread_mutex, etc).


There is one exception: when a normal futex is used as a waitqueue without any contention properties. (for example a waitqueue for worker threads) But those are both rare, and typically dont muster tasks with different priorities - i.e. FIFO is good enough.


But here, I think this is what we have with the condvar, no ? When some threads are blocked on the condvar (pthread_cond_wait), they must be woken in priority order with pthread_broadcast, but there is no "lock-owner" to boost here.
Even if all threads but one are requeued on the second futex (i.e. the mutex used with the condvar), with the patch from Seb, they are requeued in priority order and thus get woken in priority order: we don't need any priority propagation here, I think.

So, I think that the PI-futexes are the right solution for the mutexes and rwlocks. But this patch seems to me correct for condvar (FUTEX_REQUEUE), I don't think that PI-futexes will add any benefit for condvar (?). But I may have missed something ?


Also, there's a performance cost to this. Could you try to measure the impact to SCHED_OTHER tasks via some pthread locking benchmark?

Ingo

--
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/