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

Jeroen C. Visser jeroen.c.visser at gmail.com
Thu Jan 24 17:12:58 EST 2008

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.

> At present, the tick clock interval is also the quanta, so *that's* not
> the problem.
> What I suspect is that something in your code is busy-waiting, perhaps
> because there currently no interval timer support. If that is not what
> is going on, I would very much like to track this down. Can we somehow
> work together to do that?

I think the 4000ms tick explains away your worry. If not, then yes I
am available to track things down.

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.

(And that is counting FIFO 'full' interrupts, instead of FIFO 'half full'.)


More information about the coyotos-dev mailing list