Date: Sat, 09 Oct 2004 12:56:16 +1000 From: Sam Lawrance <boris@brooknet.com.au> To: Scott Long <scottl@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Noticable Delays Since Beta 3 (possible cause) Message-ID: <1097290576.836.20.camel@dirk.no.domain> In-Reply-To: <41657D63.1050605@FreeBSD.org> References: <4164BFA4.80105@unisa.edu.au> <41657D63.1050605@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-10-07 at 11:31 -0600, Scott Long wrote: > Doug White wrote: > > On Thu, 7 Oct 2004, Benjamin Close wrote: > > > > > >> I've been using each Beta Release as they come out and ever since > >>Beta 3 I've noticed delays where there never used to be any. > >>I believe this may be somehow related to ULE->BSD scheduler change. A > >>classic situation of where they now exist is when I switch virtual > >>desktops back to another xterm. It takes 4-5 seconds before I can type. > >>The machine is virtually 100% idle. Before beta3 this was not a problem > >>with almost an instant response. > > > > > > Can you provide a reproduction case? I don't notice any sort of delay when > > switching between text vtys, or changing keyboard focus in X. I've been > > using 4BSD the entire time. > > > > Are you switching between X and text vty's? There's always been a delay > > there, worse on my amd64 box than i386, but I don't do that regularly; > > much easier to just pop another xterm :) > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1097290576.836.20.camel>