Subject: Re: zstty fifo overrun
To: Paul Kranenburg <pk@cs.few.eur.nl>
From: Chuck Silvers <chuq@chuq.com>
List: port-sparc
Date: 10/26/1997 09:11:13
In message <9710261615.AA26926@cs.few.eur.nl>, Paul Kranenburg writes:
> > I hacked up the interrupt level usage stuff to not use level 14
> > for the statclock (doubling up on level 10 instead), and changed
> > a number of splhigh()s to splstatclock() in various places
> > (6 in kern_synch.c and 2 in sys_generic.c) and the problem went away.
> > pk didn't like my fix tho, and I upgraded to an IPX and didn't
> > see the problem with an unpatched kernel anymore, so I let it drop.
> 
> 1. Since the splhigh()s in kern_synch.c protect the sleep queues, you
>    cannot change those unless all ports agree on a level beyond which
>    no interrupt handler is allowed to call wakeup() et.al.

oh yea, I remember the part about wakeup() now,
that was one of your objections the last time this came up.
we could always just create splwakeup() that maps to splstatclock()
on the sparc and splhigh() everywhere else.  what exactly does
splstatclock() protect anyway?

> 2. Not using the level 14 clock would be a lose. You're giving up
>    independent profiling ticks and collection of process statistics
>    and scheduling.
> 
>    We could consider turning it off optionally on machines where it
>    interferes intolarably with the serial ports. However, I would
>    like to make sure that it is indeed `statclock()' that is holding
>    things up.  tsleep() cannot be in code path taken by the level 14
>    interrupt handler, yet your data indicates tht fifo overflows
>    mostly happen when someone is about to return from tsleep().
> 
> 
> -pk

the issue isn't that statclock() is slow, the issue is that tsleep()
is slow and having it run at splhigh() is bad.  hmm, perhaps I've
been mistaken about the whole statclock() thing... for some reason
I've been thinking that changing the splhigh()s in tsleep() to
splstatclock() was the right thing to do, but looking at it again,
I don't know why I think that anymore.  it seems like having statclock()
run in the middle of tsleep() would be fine.

let me go try making an splwakeup() and see if that does the trick.

-Chuck