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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1097290576.836.20.camel>