Date: Fri, 08 Oct 2004 21:54:35 -0700 From: Julian Elischer <julian@elischer.org> To: Sam Lawrance <boris@brooknet.com.au> Cc: Scott Long <scottl@freebsd.org> Subject: Re: Noticable Delays Since Beta 3 (possible cause) Message-ID: <41676F0B.40200@elischer.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Sam Lawrance wrote: > 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. there used to be another place that started bringing in the pages.. I think someone removed it.. (I'm just going on memories..) > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41676F0B.40200>