Messages in this thread | | | Date | Wed, 10 Jan 2007 12:47:21 +0100 | From | Pierre Peiffer <> | Subject | Re: [PATCH 2.6.20-rc4 1/4] futex priority based wakeup |
| |
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 blocked on pthread_cond_wait, the time is measured between the broadcast call and the last woken pthread).
Here are the average latencies after 5000 measures.
[only this patch is used, not the following. The system is a dual Xeon 2.80GHz with HT enable]
First case: all threads are SCHED_OTHER * with simple list: Iterations=5000 Latency (us) min max avg stddev 3869 7400 6656.73 539.35
* with plist: Iterations=5000 Latency (us) min max avg stddev 3684 7629 6787.97 479.41
Second case: all threads are SCHED_FIFO with priority equally distributed from priomin to priomax * with simple list: Iterations=5000 Latency (us) min max avg stddev 4548 7197 6656.85 463.30
* with plist: Iterations=5000 Latency (us) min max avg stddev 8289 11752 9720.12 426.45
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 be, supposing it makes sense to respect the priority order only for real-time pthreads, I can register all SCHED_OTHER threads to the same MAX_RT_PRIO priotity ? Or do you think this must be set behind a CONFIG* option ? (Or finally not interesting enough for mainline ?)
-- Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |