Re: [MiNT] MiNT context switches.

[Johan Klockars <rand@cd.chalmers.se>]

> > > switchs (as long as something happen). If nothing happen all processes are
> > > waiting and the CPU idle (except there run CPU based job).
> >
> > Just curious as there has been a long time since I worked on MiNT. How
> > many fast are the context switches in MiNT on various systems with and
> > without memory protection?
> 
> I don't have exact numbers. Maybe Draco know more because he optimzed all
> this.

I just made my old XaAES ftp site available again via my WWW pages 
(see .sig). In there a the program I wrote a couple of years ago to try out
various MiNT IPC mechanisms and context switches in general.
There is also an archive of the '98 communications on the XaAES mailing
list, from which I've extracted four of my old messages that concern the
current discussions:

****************

> > > Sockets would be better than pipes because you wouldn't have the problem
> > > of AES needing to manage 30 pipes. You will need to use connectionless
> > > (datagram) sockets. Each send will take the address of the destination
> > > socket, thus allowing a single descriptor in the AES to be used to
> > > communicate with an arbitrary number of processes.
> > 
> > How is this speedwise under MiNT compared to pipes?
...
> Do also take a look at Pmsg. The last version of oAESis heavily used this.

I actually looked through quite a bit of the MiNT source code yesterday
to figure out what the best way to do inter process communication might be.
Unfortunately, I'd say there _isn't_ one.  :-(

Unless something major has happened since the (admittedly somewhat old)
sources I looked at, most system calls under MiNT are incredibly inefficient
(a full process context seems to be built at every system call, for example,
and all parameters are copied to a new stack) and the synchronization stuff
isn't exactly speedy either:

Semaphores are always accessed via an id code, and the list of all
semaphores in the system is searched linearly for a match every time...

A message read or write searches through the entire list of tasks looking
for a corresponding writer or reader...

I didn't look at the code for Fselect etc, but since files have handles
I'd at least expect those operations not to need any table searches.
Fselect likely needs to do one call per file handle involved, though...

A further problem _might_ be that the fairness of access to semahores or
about who writes to a mailbox isn't guaranteed. I didn't look closely at
this, but it sure wouldn't be nice if a process could effectively stop all
others from doing any AES calls by simply having lots of them to do itself.
As I said, I haven't really checked if this could happen. I sure hope not!


Sending messages to the kernel via Pmsg probably wouldn't be a good idea
(even if Pmsg is indeed somewhat like a poor man's socket) since that would
require extra processes to pass on keyboard and mouse messages.
It could, however, be used for call completion notification. That way
it shouldn't be necessary to have dual direction pipes any longer (since
the return value would come via Pmsg) and then it would be enough with a
single command pipe. So the Fselect would only have to be done on one pipe
besides from the keyboard and mouse devices, which is definitely a win.
There's still the matter of the linear task list search, though...

Semaphores _could_ be the most efficient synchronization mechanism (in my
own real time kernel they are very quick indeed) but, as I described, the
MiNT implementation isn't too nice. Still, if there are fewer semaphores
than processes they might be quicker than messages, if not nearly as nice.

I'll look into the filesystem code tonight and see if that might not be
preferable after all. Without datagram sockets we still need a good way
for completion notification, though.

*************

A while ago I said that I would conduct some tests to try to figure out
what the best way to deal with process communication under MiNT might be.

I have now written a short test program (speed.tos) and made it available in
the XaAES directory on my ftp site. The source code is there as well in case
anyone wants to check it out (I just realized that I forgot to upload the
code that reports the time, though).
speed2.tos is just the Sversion (well, I picked a simple GEMDOS function 
more or less at random) test run 10000 times (all the tests run 1000 times
in speed.tos) to make a comparison with system calls under ordinary TOS
possible.


The main purpose of the code is to create two tasks and then transfer
control back and forth in various ways.
- Syield
  Useless for communication, but it should at least let you know how fast
  MiNT can switch contexts at best.
- Pmsg
  One process does a combined send/recieve call and the other separate ones.
- Fread/Fwrite on pipes
  No way to combine these.
- Fselect/Fread/Fwrite
  This is very similar to what happens in the current XaAES.

I've had some minor trouble recompiling the socket code, so there are no
tests using that. I'd be really surprised if it made any difference compared
to pipes on these tests, though.

With proper counting semaphores it is really easy to write code for the
kind of message passing we're doing here. Unfortunately, I couldn't figure
out a way to do it with what we have in MiNT...


The entire test series (which includes a few more than above) is run twice.
First with only the two invloved tasks and then with another fifty which 
are all waiting on a sempahore.
(At first I made those other fifty wait on another pipe, but that slowed
 down all the pipe tests by a factor of _25_ or so...)

I'd like to know how things work out on less powerful machines than mine,
but in short:
- All the methods are quite slow.  :-(
  It looks like a couple of thousand clock cycles per system call on my '040...
- Pmsg is fastest, unless there are many processes in the system.

Currently XaAES uses the timeout which is available for Fselect. It would,
however, be possible to get around that by having a separate task sending
timeout events. Similarly, mouse and keyboard events could be sent to the
same pipe/mbox as AES commands so that no Fselect would be needed to check
for those either.

In any case, it seems clear that anything even remotely time critical
should be done via direct calls with the current MiNT kernel.
Unfortunately, that will require semaphores, which I forgot to test the
speed of...


************

> Well, I guess one question remains. What would it take to recode parts of
> MiNT to speed these things up? Maybe on way of doing it could be choosen

Some of this is built into MiNT from the ground up, I believe, so it could
require major rewrites.

For specific features, it might be possible to improve a bit on the way MiNT
deals with message passing, but the semaphores are by design worthless for
anything but simple resource locking. I'd like to see uncounted semaphores
that never explicitly 'belongs' to a process and on which processes queue
up for access, but that would require a completely new MiNT call and might
be hard to fit into the general structure of the kernel.

> and then start to hack on MiNT as well. You said that it was far from

I don't think I should get invovled in _every_ project there is these days.
;-)

Anyway, Fenix will be miles better at these kinds of things.
We just have to hope it becomes usable one day.

> optimzed in some areas. I guess there would be a rather huge overall
> benifit as well if this were done. Just a thought....

Fortunately, the benefit for most programs would probably be very minor.
Most programs don't do huge amounts of GEMDOS/BIOS/XBIOS calls.

*******

> > If an interrupt routine could write to a pipe (which I really doubt,
...
> Would a signal do? AFAIK there is a little known MiNT-call called

Ah, I managed to forget about signals...

> Psigintr where you can get MiNT to send the process a signal on a
> interrupt.

I've heard about that, but in this case that wouldn't be useful, IMO,
since the device driver really has to be the last thing in the chain of
routines called when the mouse is moved or buttons are pressed.
If XaAES (or a device for that matter) were to handle the actual interrupt,
things like mouse accelerators and 'big screen' programs would probably
be very unhappy (the AES would not use their 'fixed' mouse information).

So, I don't think letting MiNT do interrupt->signal conversion could work.
There remains, however, the possibility of a handler routine linked into
the mouse chains sending a signal itself (don't know if that is allowed,
but it is more likely to work than writes/messages/semaphores).
Still, AFAIK, there is no way to combine Fselect waits with signal waits
(or for that matter messages or semaphores), which would mean that the
signal handling would need to be completely asynchronous with the rest
of the kernel operation. That would require semaphore locking, and since
a process of course can't expect to lock out and release itself, the
mouse handling would actually have to be handled by a separate thread.

It is possible that this really could work, but the benefits are unclear.
If the signalling happens to be significantly faster than other types of
inter-process communication, this could be a good way to handle mouse
information (IIRC, signals of the same type can't be queued, so it wouldn't
work for the normal non-direct calls). I'll add some kind of signalling
test to my MiNT IPC test program to check this out.

Naturally, a handler like this would have the same (or even worse) trouble 
with shutting down as a built in device driver.


-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)