[coyotos-dev] Usermode interrupt handling delayed until end of quanta?

[Jonathan S. Shapiro]

On Thu, 2008-01-24 at 17:12 -0500, Jeroen C. Visser wrote:
> Hello Jonathan,
> 
> On Jan 24, 2008 9:23 AM, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> > So the more I thought about this, the more it worried me. If we assume
> > that your patch is NOT applied, here is what ought to be happening:
> >
> >  1. Interrupt goes off. IrqWait process is moved to the ready queue.
> >  2. Assuming nothing is busy waiting, you would reasonably expect the
> >     IrqWait process to run fairly soon, even with pure round-robin.
> >
> > The current tick clock is set at 5ms (200/sec), so that's almost
> > certainly not the problem.
> 
> Sorry for the confusion: I was running at a 4000ms tick. (Tracing
> every function call in the kernel and outputting the result via serial
> without getting overwhelmed.) It was a strange experience to type a
> character, then wait 4000ms for the serial driver to kick in and
> display them.

Well, yes, that would certainly do it. If you restore the tick counter
to 5ms, does responsiveness improve?

> Having said that... I am running my UART at 115200 and the FIFO is 64
> bytes in size. My math is naively as follows:
> 
> 115200 bits/s
> 14400 bytes/s
> 14400 bytes/s  /  64 bytes/FIFO = 225 FIFO/s
> 225 FIFO/s = ~4.4ms/FIFO
> 
> So if I run at 115k2 I need to service the FIFO more often than once
> per 4.4ms. When the real scheduler is implemented this driver would
> need to take precedence over most applications it seems.

Yes. This is true in the same way that the in-kernel serial driver does
so. It's just that the priority is expressed through the scheduler
rather than through a fixed hierarchy of interrupt priorities.

shap