Submitted by “ExAmour is an exokernel, a kernel bound to ensure a fair access to hardware resources for applications. The management of those resources is up to the applications (called environment under ExAmour). Kernel specifications: it presently works on x86-32; each application can define its own memory management policy, its own scheduling policy an use its own drivers (hardware or logical); it is multi segmented, no pagination, no overlap between segments in order to avoid exploitation of buffers overflows, heap overflow or off by one; there is no drivers in kernel mode. (increases the security, reliability of the system).”
Sounds like there is a lot of messages going around, this could slow things down.
Like the old Mac co-operative time-sharing it reads as if a lazy programmer could demand large time-slices for their code even when not needed and thus slow other programs down.
In the hands of good programmers it reads as if it can finely tune the time-slicing to programs, but how well will it handle a poorly designed env?
Poorly designed envs can be managed by a “load balancing” mechanism in the timeslices component of the kernel.
For example when the system doesn’t have enough timeslices left, it will ask to the most consuming timeslice env to give back some of its timeslices…
I still have to design it properly, since it is still more or less inside my head but there is a way to limit the nasty effects.
However of course poorly envs will always been nasty even — a little bit — for the system. One of the assumptions of ExAmour is that programmers are able to do things correctly so we try to find ways to limit the nasty effects but not to avoid it. It is not possible anyway, not if we keep the exokernel approach.
The kernel uses both a co-operative and preemptive approach, combined with a good load balancing mechanism and a minimal coding level from programmers, we expect it to be sufficient… Especially with the news things in the computer world of these last years like VM
>> when the system doesn’t have enough timeslices left, it will ask to the most consuming timeslice env to give back some of its timeslices…
And what happens if the env does not return them?
>One of the assumptions of ExAmour is that programmers are able to do things correctly
But even the best programmers make mistakes, that could be a dangerous assumption.
What I am really asking which way you are leaning. (1) Put an upper limit in the size of the time slices a env can ask for? Or (2) prevent any single env from having more than a certain percentage of the timeslices.
The reason I am asking is I am working on simple sound driver for BeOS/Haiku, but it uses software instead of hardware to create precision timing. I have come across weird problems when using high percentages of available CPU time. In the process I found that how I split the loads and which OS timing calls I make result in differences in performance.
> And what happens if the env does not return them?
If the env doesn’t return them, the kernel will ask to the 5-10 other envs. Actually it asks from the most consuming env to the least consuming. And if nobody is okay it simply kills the most consuming one.
Envs can return less timeslices than asked, they take the risk to be killed if all the envs in the system returned a little memory and if it is the most consuming one. Otherwise no risk, the non returning env is the first target to be killed.
But one more time, this mechanism is still in my head, I tried to handle the differents needs (like certified timeslice: timeslices that can’t be interrupted) but everything still need to be clerly designed and implemented in the kernel.
Presently this load balancing mechanism is then not present and there is no timeslice allocation limit but don’t worry, a limit should be present as well as the load balancing mechanism in the 0.2 version.
Oh, about the percentage, this is precisely one of the goal of the load balancing mechanism, when it becomes ritical it reequilibrates the percentage of use between the envs. Consider 100% as 1 second of execution from one hand and the number of running envs on the other hand.
The IPC implementation on L4 microkernels is really great and does not have the performance issues found on Mach… so, a good IPC implementation does not slow things down.
The “environments” (OS personalities) implement all the stuff like memory management, scheduling, security which will be available for the application developer. I do not think the application developers will work directly with all that low level stuff, so, at the end, just good implementations will be used.
The really great on this approach is that several algorithms for the same functionality can be developed and optimized depending on the final feature, so, the developer can just choose and plug the better algorithm for his/her application.
Edited 2006-12-13 21:51
>a good IPC implementation does not slow things down.
Sorry, my mistake. I am working in BeOS and just remembered after reading your reply that there was some problem with double memory copies in BeOS, and that message passing was very fast on the Amiga because only a single pointer was passed (flat memory model). My error.
>I do not think the application developers will work directly with all that low level stuff
So there are defaults that run unless the programmer overrides them?
>several algorithms for the same functionality
I am not clear, you supply the algorithms as part of the OS (libraries?) and the programmer just chooses what they want to call, or is the algorithm code in the application itself?
Actually for the present x86-32 bits version of ExAmour, there is no real IPC model. Memory can be shared through segments. It is thus only a new entry in the env’s ldt.
Of course not all programmers will work at low level (even if this low level is not worse than other high level code in my opinion). Actually a programmer can choose either to use preexisting librairies or to roll on its own.
In other words, you supply the algorithms in librairies and the programmer chooses what they want to call indeed.
Earl Colby Pottinger wrote:
-“Sounds like there is a lot of messages going around, this could slow things down.”
iirc exokernels is pretty much the opposite of that. like in a traditional kernel you ask for resources, but instead of getting them in an abstracted form which can only be used by the functions that the kernel offers, you are given physical hardware functionality and adresses. in order to utilize these you will need to supply the actual low level code. so if you allocate a chunk of memory, instead of getting a handle that you pass on to kernel functions, you will get a physical memory block. as such, you will have to write your own memory management, as crude or sofisticated as you like.
naturally this is more work, but for cases where you want to get the greatest performance, an exokernel offers great flexibility and pretty much no abstraction overhead other than that you yourself might implement.
that said, it’s been along time since I read about exokernels, so I really should look this up to make sure I’m not talking out of my arse here.
You are perfectly right valhalla.
But if you want some good litterature about exokernel here are two links:
– pdos.csail.mit.edu/exo.html from the PDOS. Now it becomes to be old.
– http://www2.lifl.fr/~deville/articles/INRIA-RR-5161.pdf A more recent exokernel project on a java smart card.
It gives an idea of how we consider the future of ExAmour but with security issues in mind
Edited 2006-12-13 23:12
Thanks I will try to read them later.
Do you always have to write low-level code? Are there not standard libraries included in the OS that you can use instead so you only need to write specialize code for the important features?
Note: I am thinking bare-boned libraries that may be slow in operation because they are full of all the checks and balances to insure there are not errors in their implementation – they just get the basic job done – no more.
What is this? An ubertechnical discussion I can barely follow! Finally OSAlert is back from the bloody trenches of the last few weeks!
dhilus, just curious… on your list of possible evolutions, you mention x86-64 support. Once you enter 64 bit mode, the segmentation support completely disappears. (Let’s just ignore the slight remnants that were kept solely to make creating Win64 easier) How are you planning on coping with that?
But with such a large address space it should be easy to insure no two memory allocations share adjoining address spaces. Even larger variables like arrays, strings and structures can be in individual allocations so any overflowing access hits ‘no-man’s land’ before it can affect other variables.
should be is not it is.
I don’t like this kind of assumptions and I prefer to rely on the hardware if it can do the job for me.
With x86-32 and segmentation the processor does the job for us which is good. For x86-64 I don’t know exactly how it works… But I guess they didn’t removed segmentation without setting up another powerful system.
I still have to read in depth the modifications brought with x86-64 but if the segmentation is no longer useful and the paging is good enough we will use it.
A ExoKernel doesn’t try to find a generic way to handle all architecture, segmentation appeared the best thing to do to us for the 32 bits architectures but it doesn’t mean it will be the same for 64 bits.
The goal stays to take the best from each architecture even if it implies to redo a large part of some components of the kernel between architectures.
However the kernel is designed to reduce the port effort,
“there IS no drivers”
Over the past year or bit more the basic mistake of when to use “is” or “are” seems to be getting more – it is not as though it’s difficult .
It doesn’t seem to be because the author’s mother tongue is not English because the rest of the articles always have decent English in them
My English isn’t good either – but that is just too basic a mistake for my taste – & it is just because slang use has managed to get into mainstream language .
Just IMO
>Over the past year or bit more the basic mistake of when >to use “is” or “are” seems to be getting more – it is not >as though it’s difficult .
>It doesn’t seem to be because the author’s mother tongue >is not English because the rest of the articles always >have decent English in them
I’m not english, not more than the rest of the present ExAmour team. Actually we are french
Edited 2006-12-15 16:14
Anyone see which license this is under?
ExAmour is a GPL kernel