More serial port speed thoughts

Hi All,

I've had some more thoughts about how to improve servers such as the serial
server which generate lots of interrupts. I've discussed this briefly with
Andy, and it seems a reasonable approach.

Originally when I added the code to allow the user of the real-time
scheduler queue the plan was to allow things like the rs232 server to run
in this high priority queue and get good response to interrupts. The
downside of this of course is that this means user requeusts from the server
also get run at this high priority and potentially blocks other more
deserving requests going on elsewhere.

With the introduction of a kernel arbitrated semaphore mechanism (I've got
to do some experiments with Gary's code to work out the details yet) there's
now a much cleaner solution. Instead of one port for handling interrupts
and requests we split the server into two threads, each of which manages one
port. The first thread runs in the realtime queue and manages the port to
which interrupt messages are sent. The second thread runs in the time-share
queue and manages the publicly visible port (ie registered with the namer)
that handles user requeusts.

A couple of things drop out of this implementation: We only run at a
high priority for the kernel generated M_ISR messages. We only have to do a
quick check that the messages delivered to the interrupt handler port are
M_ISR's from the kernel instead of having to go through a long list of
possible messages.

Assuming all goes well when I come to try this, it may be of use in some of
the other servers that handle a lot of interrupts, and will hopefully avoid
some of the starvation problems that currently exist if we're running things
in the realtime queue (eg. one of my performance analysis tools causes me to
loose keyboard interrupts).

On a more minor performance note, the 1.3.3 implementation of the port I/O
code is pretty nasty as it does lots of calling and jumping (major
overheads) to do what in essence are single CPU instructions. One of the
things I tweaked a few month back as part of my performance overhaul was to
use inline assembly code for these functions if the code's compiled under
GCC.

                                Regards,
                                Dave
Received on Thu May 4 07:28:50 1995