Hi,
Just few comments for my understanding:
Ingo Molnar a écrit :
* Sébastien Dugué <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
