Re: support library for servers

>>>>> "AV" == Andrew Valencia <vandys@cisco.com> writes:

>> * improve the service selection on a received message. (As long as
>> VSTa needs about 10-20 the time of similar systems for a context
>> switch it doesn't matter.)

AV> I'm not sure what this means. If you're saying that VSTa context
AV> switches are 10-20 times slower than other similar systems, what
AV> is it we're doing that they don't? Or did you mean something
AV> else?

I don't mean anything else. But as everything - it depends.

I remember some messages about context switch time of VSTa. They claim
(as I remember) all not to be exact mensured and are anywhere between
60 us and 200 us on 486/?? and pentium.

We are playing here with a (non free) system named L3. It needs 10 us
to pass a zero length message from one process to another on a 486/50.
Up to 8 byte message are about the same speed.

From memory: QNX takes about 5 that time.

It depends a bit of what we call similar. Both systems are micro
kernel. Both have a couple of servers and (almost) no driver related
software in the kernel. (And both make exceptions for speed -- I
remember, that rs232 support lead to kernel modifications, or am I
wrong? L3 has rs232 support partially in the kernel. But in any case
it is not essential.)

Where is the difference? (From probably least to more significant.)

1) L3 doesn't impose the "everything is a file" policy by the kernel.
(Even if I consider this a good thing at the server level I don't like
the kernel burned manner.) This may or may not save overhead - I don't
know.

2) L3 has not that many protection policy in the kernel. Only the msg
sending process is identified by the kernel. (A VSTa-ish policy would
need a extra server. Such at least 2 extra message passings at a
"M_CONNECT".)

3) L3 is only implemented for [3|4|5]86. Currently with no
multiprocessor support in mind. I think this "wastes" some time.

4) L3 has only synchronous unidirectional message passing. A message
is in principle passed to another process in a rendezvous and there is
not reply. If you need on you have to receive a message from that
process.

Because this would cost a lot of kernel entries and one of them is
about 100 clock cycles, they have some kernel call introduced to send
and receive a reply, send a reply and receive the next message and
such. These kernel calls don't do anything special, they only spare
some ring3->ring0 switches for often used sequences. There servers
know about the optimization and prefer these calls.

5) L3 is optimized for message passing. Up to 8 byte are transfered in
the processor registers. Everything else is copied into kernel memory
and temporary mapped to the receiver.

Also the rest of L3 is widely optimized for speed. Jochen Liedke, who
wrote the most of it, didn't fear to write large parts in assembly.
And he spend some time in things like page-adjusting of thread control
block, spare cache and TLB misses and so on.
(But at top of the kernel there is nothing intel specific except what
the compiler generates ;-)

So far. As you can see it is not much. Mostly optimization (which will
ever break the portability (of the kernel not the servers)) and the
old remove policy from the kernel.

/Joerg

-----------------------------------------------------------------------------
Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de
Rietzstr. 32b |
01139 Dresden |
Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8

WWW: <a href=http://www.inf.tu-dresden.de:~jw6/top.html> (click here) </a>
Received on Wed Dec 28 10:53:16 1994