Date: Fri, 8 Oct 2004 23:46:11 -0400 From: Marc Ramirez <marc.ramirez@bluecirclesoft.com> To: freebsd-current@freebsd.org Cc: Sam Lawrance <boris@brooknet.com.au> Subject: Re: Noticable Delays Since Beta 3 (possible cause) Message-ID: <200410082346.16570.marc.ramirez@bluecirclesoft.com> In-Reply-To: <1097290576.836.20.camel@dirk.no.domain> References: <4164BFA4.80105@unisa.edu.au> <41657D63.1050605@FreeBSD.org> <1097290576.836.20.camel@dirk.no.domain>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Friday 08 October 2004 10:56 pm, Sam Lawrance wrote: > I think I've found the cause of the delays. > > The problem was consistently reproducible with getty processes which are > swapped out (ie 'ps' shows RSS=0 and state=IWs+). > > Since the problem was identifiable when starting to type at a vty, I > traced the problem back through: > > ttyinput() : tty.c > ttwakeup() : tty.c > wakeup() : kern_synch.c > sleepq_broadcast() : subr_sleepq.c > sleepq_resume_thread() : subr_sleepq.c > setrunnable() : kern_synch.c > > Notice in setrunnable() how wakeup(&proc0) is wrapped by #ifndef SMP? > This means that scheduler() : vm/vm_glue.c, which tsleeps on proc0, is > not awoken to traverse the process list and swap the process in. > > scheduler() tsleeps for a maximum of maxslp * hz / 2. maxslp on all > archs appears to be 20, so the actual wakeup intended by ttwakeup() may > not occur for up to 10 seconds. I think I agree, FWIW. Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) http://www.bluecirclesoft.com http://www.mrami.com (personal) [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBZ18Ig1EgpGw750IRAtAqAKC4yHxE4T7Lc1d5THNTirkxaleeHACbBHnl Hf/xn42IsBg/GpaiZilUiL8= =MEMW -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410082346.16570.marc.ramirez>