Pierre Peiffer wrote:
> Here are the average latencies after 5000 measures.
> [...]
Use something more realistic. I suggest using the Volano benchmark
under your favorite JVM. I found it to be quite representative and you
get a nice number you can show.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 44
Pierre Peiffer wrote:
> But there can be a performance impact when several processes use
> different futexes which have the same hash key.
> In fact, the plist contains all waiters _of_all_futexes_ having the same
> hash key, not only the waiters of a given futex. This can be more a
> problem,
s/c
On Wed, 2007-01-10 at 17:29 +0100, Pierre Peiffer wrote:
> >
> > Is this really necessary? The rtmutex will priority sort the waiters
> > when you enable priority inheritance. Inside the wake_futex_pi() it
> > actually just pulls the new owner off another plist inside the the
> > rtmutex structur
Daniel Walker a écrit :
On Tue, 2007-01-09 at 17:16 +0100, Pierre Peiffer wrote:
@@ -1358,7 +1366,7 @@ static int futex_unlock_pi(u32 __user *u
struct futex_hash_bucket *hb;
struct futex_q *this, *next;
u32 uval;
- struct list_head *head;
+ struct plist_head *
On Tue, 2007-01-09 at 17:16 +0100, Pierre Peiffer wrote:
> @@ -1358,7 +1366,7 @@ static int futex_unlock_pi(u32 __user *u
> struct futex_hash_bucket *hb;
> struct futex_q *this, *next;
> u32 uval;
> - struct list_head *head;
> + struct plist_head *head;
>
Yes, I agree with all, that was what I have in mind too.
And by registering all SHED_OTHER threads with the same priority MAX_RT_PRIO, we
have exactly this behavior, I think :
* the plist, when used with only one priority, behaves exactly as a simple list
(plist is a double simple list: first
On Wed, Jan 10, 2007 at 12:47:21PM +0100, Pierre Peiffer wrote:
> So, yes it (logically) has a cost, depending of the number of different
> priorities used, so it's specially measurable with real-time threads.
> With SCHED_OTHER, I suppose that the priorities are not be very distributed.
>
> May
Pierre Peiffer a écrit :
Ulrich Drepper a écrit :
I have never seen performance numbers for this. If it is punishing
existing code in a measurable way I think it's not anacceptable default
behavior.
May be, supposing it makes sense to respect the priority order only for
real-time pthreads,
Ulrich Drepper a écrit :
I have never seen performance numbers for this. If it is punishing
existing code in a measurable way I think it's not anacceptable default
behavior.
Here are some numbers. My test program measures the latency of pthread_broadcast
with 1000 pthreads (all threads are
On Tue, 2007-01-09 at 17:16 +0100, Pierre Peiffer wrote:
> @@ -133,8 +133,8 @@ struct futex_q {
>* Split the global futex_lock into every hash list lock.
>*/
> struct futex_hash_bucket {
> - spinlock_t lock;
> - struct list_head chain;
> + spinlock_t
Pierre Peiffer wrote:
> This patch makes use of plist (pirotity ordered lists) instead of simple
> list in
> futex_hash_bucket.
I have never seen performance numbers for this. If it is punishing
existing code in a measurable way I think it's not anacceptable default
behavior.
--
➧ Ulrich Dreppe
Hi,
Today, all threads waiting for a given futex are woken in FIFO order (first
waiter woken first) instead of priority order.
This patch makes use of plist (pirotity ordered lists) instead of simple list in
futex_hash_bucket.
---
futex.c | 66 +++
12 matches
Mail list logo
