Re: Noticable Delays Since Beta 3 (possible cause)

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.