linux-kernel - Re: [PATCH 2.6.20-rc4 1/4] futex priority based wakeup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45A4D249.8080904@bull.net>
Date:	Wed, 10 Jan 2007 12:47:21 +0100
From:	Pierre Peiffer <pierre.peiffer@...l.net>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Dinakar Guniguntala <dino@...ibm.com>,
	Jean-Pierre Dion <jean-pierre.dion@...l.net>,
	Ingo Molnar <mingo@...e.hu>, Jakub Jelinek <jakub@...hat.com>,
	Darren Hart <dvhltc@...ibm.com>,
	Sébastien Dugué <sebastien.dugue@...l.net>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/