[Date Prev][Date Next]
Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
- To: Hallvard Breien Furuseth <firstname.lastname@example.org>, openldap-commit2devel@OpenLDAP.org
- Subject: Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
- From: Howard Chu <email@example.com>
- Date: Wed, 15 Mar 2017 13:27:12 +0000
- In-reply-to: <WMfirstname.lastname@example.org>
- References: <E1co6tc-00053T-RO@euler.openldap.org> <email@example.com> <WMfirstname.lastname@example.org>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46a2
Hallvard Breien Furuseth wrote:
On 15. mars 2017 12:15, openldap-commit2devel@OpenLDAP.org wrote:
Author: Howard Chu <email@example.com>
Date: Wed Mar 15 11:13:09 2017 +0000
Fixes for multiple threadpool queues
Remove poolq_hash, it wasn't distributing work evenly to the queues.
Not surprising when it was hashing the address instead of contents
of a local variable. Whatever that intended to achieve, it looks
to me like rand_r() would have done the same but better.
It was hashing the bytes of arg. In the common case of the slapd_daemon_task
submitting jobs to the pool, arg was the socket descriptor of an active
connection, so this was always distributing those evenly. But in other cases
where arg was a context pointer, the result was heavily skewed.
hash was pointlessly slow in that it walked a byte at a time, it
could have hashed better with fewer operations.)
for a 4 or 8 byte arg this was hardly important.
I guess I should have looked closer at that code earlier:-)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/