Date: Sun, 7 May 2006 19:04:30 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Kris Kennaway <kris@obsecurity.org> Cc: performance@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, current@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) Message-ID: <20060507230430.GA6872@xor.obsecurity.org> In-Reply-To: <20060507214153.GA5275@xor.obsecurity.org> References: <20060506150622.C17611@fledge.watson.org> <20060506221908.GB51268@xor.obsecurity.org> <20060507210426.GA4422@xor.obsecurity.org> <20060507214153.GA5275@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Sun, May 07, 2006 at 05:41:53PM -0400, Kris Kennaway wrote:
> static int
> kern_sigtimedwait(struct thread *td, sigset_t waitset, ksiginfo_t *ksi,
> struct timespec *timeout)
> {
> ...
> td->td_sigmask = savedmask;
> SIGSETNAND(td->td_sigmask, waitset);
> signotify(td);
> error = msleep(&ps, &p->p_mtx, PPAUSE|PCATCH, "sigwait", hz);
>
> i.e. several threads in the process are all sleeping for 1 tick and
> then doing a thundering herd on the same proc lock when they wake up.
Oops, actually hz=0; it comes via sigwait(2). It's still a thundering
herd situation though.
I also profiled the sleepq_broadcast call to look at thundering herds
from wakeup(), and I found that the umtxq_chain is waking the
following distribution of CPUs at once:
Before patch:
Freq #CPUs
1111 1
366 2
136 3
54 4
17 5
2 6
After patch:
Freq #CPUs
1139 1
332 2
139 3
44 4
12 5
2 6
i.e. apparently not a large difference, but still a large proportion
of cases where multiple CPUs are woken at once on the same chain.
Kris
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFEXnz+Wry0BWjoQKURAt9bAJ98pfbOhmC9J0RECAq9WEB9IEi5mwCfQkp7
rN1OtiYv5coGIatwx6cntG4=
=9lr+
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060507230430.GA6872>