From: Bernardo Innocenti <bernie@develer.com>
To: lkml <linux-kernel@vger.kernel.org>, OpenLDAP-devel@OpenLDAP.org
Cc: Giovanni Bajo <rasky@develer.com>, Simone Zinanni <simone@develer.com>
Subject: sched_yield() makes OpenLDAP slow
Date: Thu, 18 Aug 2005 02:50:16 +0200 [thread overview]
Message-ID: <4303DB48.8010902@develer.com> (raw)
Hello,
I've been investigating a performance problem on a
server using OpenLDAP 2.2.26 for nss resolution and
running kernel 2.6.12.
When a CPU bound process such as GCC is running in the
background (even at nice 10), many trivial commands such
as "su" or "groups" become extremely slow and take a few
seconds to complete.
strace revealed that data exchange over the slapd socket
was where most of the time was spent. Looking at the
slapd side, I see several calls to sched_yield() like this:
[pid 8780] 0.000033 stat64("gidNumber.dbb", 0xb7b3ebcc) = -1 EACCES (Permission denied)
[pid 8780] 0.000059 pread(20, "\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344\17\2\3"..., 4096, 4096) = 4096
[pid 8780] 0.000083 pread(20, "\0\0\0\0\1\0\0\0\4\0\0\0\3\0\0\0\0\0\0\0\222\0<\7\1\5\370"..., 4096, 16384) = 4096
[pid 8780] 0.000078 time(NULL) = 1124322520
[pid 8780] 0.000066 pread(11, "\0\0\0\0\1\0\0\0\250\0\0\0\231\0\0\0\235\0\0\0\16\0000"..., 4096, 688128) = 4096
[pid 8780] 0.000241 write(19, "0e\2\1\3d`\4$cn=bernie,ou=group,dc=d"..., 103) = 103
[pid 8780] 0.000137 sched_yield( <unfinished ...>
[pid 8781] 0.050020 <... sched_yield resumed> ) = 0
[pid 8780] 0.000025 <... sched_yield resumed> ) = 0
[pid 8781] 0.000060 futex(0x925ab20, FUTEX_WAIT, 33, NULL <unfinished ...>
[pid 8780] 0.000026 write(19, "0\f\2\1\3e\7\n\1\0\4\0\4\0", 14) = 14
[pid 8774] 0.000774 <... select resumed> ) = 1 (in [19])
The relative timestamp reveals that slapd is spending 50ms
after yielding. Meanwhile, GCC is probably being scheduled
for a whole quantum.
Reading the man-page of sched_yield() it seems this isn't
the correct behavior:
Note: If the current process is the only process in the
highest priority list at that time, this process will
continue to run after a call to sched_yield.
I also think OpenLDAP is wrong. First, it should be calling
pthread_yield() because slapd is a multithreading process
and it just wants to run the other threads. See:
int
ldap_pvt_thread_yield( void )
{
#if HAVE_THR_YIELD
return thr_yield();
#elif HAVE_PTHREADS == 10
return sched_yield();
#elif defined(_POSIX_THREAD_IS_GNU_PTH)
sched_yield();
return 0;
#elif HAVE_PTHREADS == 6
pthread_yield(NULL);
return 0;
#else
pthread_yield();
return 0;
#endif
}
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
next reply other threads:[~2005-08-18 0:50 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 0:50 Bernardo Innocenti [this message]
2005-08-18 0:47 ` sched_yield() makes OpenLDAP slow Con Kolivas
2005-08-18 10:48 ` Maciej Soltysiak
2005-08-18 1:07 ` Joseph Fannin
2005-08-18 2:25 ` Bernardo Innocenti
2005-08-18 2:58 ` Nick Piggin
2005-08-19 3:10 ` Bernardo Innocenti
[not found] <4303DB48.8010902@develer.com.suse.lists.linux.kernel>
[not found] ` <20050818010703.GA13127@nineveh.rivenstone.net.suse.lists.linux.kernel>
[not found] ` <4303F967.6000404@yahoo.com.au.suse.lists.linux.kernel>
[not found] ` <43054D9A.7090509@develer.com.suse.lists.linux.kernel>
2005-08-19 3:19 ` Andi Kleen
2005-08-19 3:30 ` Bernardo Innocenti
-- strict thread matches above, loose matches on Subject: below --
2005-08-19 6:03 Howard Chu
2005-08-19 6:34 ` Nick Piggin
2005-08-19 6:59 ` Chris Wedgwood
2005-08-19 22:45 ` Howard Chu
2005-08-19 10:21 ` Nikita Danilov
2005-08-19 23:10 ` Howard Chu
2005-08-20 13:23 ` Nikita Danilov
2005-08-20 19:49 ` Howard Chu
2005-08-20 22:08 ` Nikita Danilov
[not found] <4D8eT-4rg-31@gated-at.bofh.it>
2005-08-20 3:20 ` Robert Hancock
2005-08-20 4:18 ` Nick Piggin
2005-08-20 18:38 ` Howard Chu
2005-08-20 20:57 ` Lee Revell
2005-08-20 21:24 ` Howard Chu
2005-08-21 0:36 ` Nick Piggin
2005-08-21 11:33 ` Nikita Danilov
2005-08-22 8:06 ` Howard Chu
2005-08-20 21:50 ` Lee Revell
2005-08-21 1:04 ` Robert Hancock
2005-08-22 11:44 ` linux-os (Dick Johnson)
2005-08-22 14:26 ` Robert Hancock
2005-08-23 11:17 ` linux-os (Dick Johnson)
2005-08-23 12:07 ` Denis Vlasenko
2005-08-24 3:37 ` Lincoln Dale
[not found] <43057641.70700@symas.com.suse.lists.linux.kernel>
[not found] ` <17157.45712.877795.437505@gargle.gargle.HOWL.suse.lists.linux.kernel>
[not found] ` <430666DB.70802@symas.com.suse.lists.linux.kernel>
2005-08-20 13:48 ` Andi Kleen
2005-08-21 19:47 ` Florian Weimer
2005-08-22 5:09 ` Howard Chu
2005-08-22 13:06 ` Andi Kleen
2005-08-22 18:47 ` Howard Chu
2005-08-22 13:20 ` Florian Weimer
2005-08-22 23:19 ` Howard Chu
2006-01-14 19:29 Howard Chu
[not found] <5uZqb-4fo-15@gated-at.bofh.it>
2006-01-14 22:47 ` Robert Hancock
2006-01-24 22:59 e100 oops on resume Stefan Seyfried
2006-01-24 23:21 ` Mattia Dongili
2006-01-25 9:02 ` Olaf Kirch
2006-01-25 12:11 ` Olaf Kirch
2006-01-25 13:51 ` sched_yield() makes OpenLDAP slow Howard Chu
2006-01-25 14:38 ` Robert Hancock
2006-01-25 17:49 ` Christopher Friesen
2006-01-26 1:07 ` David Schwartz
2006-01-26 8:30 ` Helge Hafting
2006-01-26 9:01 ` Nick Piggin
2006-01-26 10:50 ` Nikita Danilov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4303DB48.8010902@develer.com \
--to=bernie@develer.com \
--cc=OpenLDAP-devel@OpenLDAP.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rasky@develer.com \
--cc=simone@develer.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox