Re: ITS#3950

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:
> I know it's not going to be very indicative, since it's mixing reads and
> writes and it's yielding overall execution time and not operations rate;
> but it looks indicative.
>   

Yes, as an indicator of the problem I'm sure it's Good Enough.

I found that recompiling daemon.c with #undef HAVE_EPOLL brought 
performance back in line with my other results for the BROKEN/select 
case, going down from 17 minutes back to ~25 seconds. So there appears 
to be some bad interaction between select() and epoll() in the same 
process, how nice.

Notice http://article.gmane.org/gmane.linux.kernel/368066 - the 
pthread_mutex_unlock() function is broken as well, which is what 
necessitated some of these additional yield() calls in the first place.

Other solutions I've investigated: pthread_attr_setscope( xxx, 
PTHREAD_SCOPE_PROCESS ) to request that slapd's threads only compete 
within their own process. But this returns Unsupported, so that option 
is out.

Playing with scheduling policies and thread priorities requires root 
access, so that can't be done for a slapd running as a non-root user.

All in all the Linux 2.6 kernel is pretty unsatisfactory at the moment, 
and there are no clean fixes presenting themselves.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/