RE: [MiNT] kernel 1.15.10b fragmentation

["Sven Karlsson" <svenka@it.kth.se>]

Hi Henk,

> We dont all have 68080's at 500Mhz. Speed is an issue. Adding
> communication
> protocols to the operating environment has significant influence
> on performance.

I couldn't have said it better myself. The message scheme I proposed is very
fast and a message is sent or received in a few hundred processor cycles.

Now that I think about it there is another scheme in Fenix that could
perhaps fit here.

In Fenix, and like most UNIXes, a fixed part of the adress space is
dedicated to the kernel and servers. (The top part. The exact amount of
memory can be configures at boottime.) A memory map would thus be:

+-------------+ 4GB
|    Kernel   |
|     and     |
|    Server   |
+-------------+ 4GB-x
|             |
|    user     |
|   process   |
|             |
+-------------+
| illegal     | one or two pages to catch null pointers
+-------------+

The Fenix kernel has a primitive that are similar to a trap and allows a
thread to migrate from a user process into a server process. The server are
trusted kernel level services not unlike root processes in UNIXes. The
kernel and the servers can access the memory of the currently running user
process. The process identity (in Fenix called adress space) of each thread
is kept so when a thread executing in a server is scheduled the
corresponding user process memory map is switched in.

This is a very low overhead call and will make it possible to extend the
MiNT kernel with for instance proper socket calls without adding excessive
trap entries. You will only need one.

The Fenix kernel checks that the calling adress space is allowed to use the
server and that the call is legal. The mmu is used for this so again this is
a very low latency call. You will simply get a page fault if you try to
access a server that you are not allowed to.

The disadvantage of all this is however that the servers must be
multithreaded so you will also need synchronization primitives.

When I think of it it would probably be wise to add semaphore/mutex to my
earlier proposal. Using a systemwide semaphore would make wind_unpdate quite
efficient.

What are the major performance bottlenecks in the AES? I would figure the
event functions?

The Fenix kernel has monitor type sychronization as well and that could be
used to maintain access to a shared memory region that holds all mouse
information (x,y,mousebuttonstate etc.) However, I do think that this is
only interesting when the application keeps track of a dragged mouse.

I'm no AES expert but I would think that there really isn't that much
communication needed between the server part and the user part. I would
think only these are needed to be exchanged:

* Events
* clip rects (these could be communicated in a shared memory buffer)
* the location and size of windows or rather messages telling that a window
is moved, resized or whatever and corresponding messages that says that this
is ok.

Each Fenix message holds betwen 20 and 28 bytes of data so there is plenty
of room for authentication data (if needed) and payload data. IIRC last time
I checked I got up to approximately 8000 messages per second on a 8MHz ST
(sent and received). This was of course without memory protection and the
figure could go up or down when using a faster processor with memory
protection.

Best regards
 Sven