[cap-talk] Cap type safe OS questions

[Ben Kloosterman]

I think this is mainly due to the high Context switch costs of the common
separate user address space , multiple privilege levels OS. The Singularity
paper " Singularity - Rethinking the Software Stack " shows good performance
with an Asych  IPC with an unoptomized kernel compared to L4.  

It depends on the type of Synch ( ie whether it runs the kernel code on the
user thread or whether it invokes a kernel thread ) but  common sense would
indicate this as well with most Asynch you have at least 2 context switches
for a send-reply with Synch you have one ( as the return is cheap) . If your
switches are costing 1000 cycles  it will be 2000 cycles which is quite
costly. However if your context switches take 100 cycles even an Asych
switch is 200 cycles which is almost a factor of 5 better than a Linux
(Synch) call . At this level ( 100 cycle context switches) IPC costs are not
as important in overall performance and architectural improvements can make
more major gains.

In addition by allowing Asych ( instead of unbuffered Synch)  the receiver
has the option to have a  user app servicing messages 
A) immediately invoke it if it is waiting for the message resulting in low
latencies . OR
B) Add it to a queue which can be batch processed resulting in more
throughput due to better use of the CPU cache. 

And I think Asynch better matches modern multi core hardware  , distributed
communication and applications with events such as a GUI apps and where they
will go in future. 

Another more modern paper arguing against all Micro kernel designs for
performance is "The Cost of IPC: an Architectural Analysis"
http://www.ideal.ece.ufl.edu/workshops/wiosca07/Paper2.pdf

The paper contradicts  Liedtke's earlier L4 work is based on the following 

- Heavy message copy costs 
	We dont copy messages.
- Heavy context switch cost especially by mapping memory and the TLB flush
cost.
	We dont remap memory and dont need to flush the TLB , more
importantly the cost of a context switch is low. 
- Lots of short messages for a few pieces of data.
	Our messages are not fixed size. 
- Memory is getting slower
	We should be able to keep memory use down to a minimum. Though
obviously the 64 bit GP registers add to the amount that needs to be saved.

Regards, 


Ben

>-----Original Message-----
>From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
>bounces at mail.eros-os.org] On Behalf Of Sam Mason
>Sent: 02 Augustus 2009 11:42 PM
>To: cap-talk at mail.eros-os.org
>Subject: Re: [cap-talk] Cap type safe OS questions
>
>On Sun, Aug 02, 2009 at 03:48:39PM +0800, Ben Kloosterman wrote:
>> At present the kernel only access "user" address spaces to add
>> received messages to the queue
>
>Most of the micro-kernel research (i.e. just not ocap related) says
>that unbuffered, synchronous IPC is the easiest way to get reasonable
>performance.
>
>The L4 work has a few good documents on this and a lot of the EROS work
>is very complementary to this; the following are a fun set:
>
>  http://l4ka.org/publications/1996/ukernels-must-be-small.pdf
>  http://www.eros-os.org/papers/iwooos96-ipc.ps
>  http://srl.cs.jhu.edu/~shap/proposal/proposal.ps
>
>As I understand it, the effects of cache dominate when you're doing lots
>of little calls and returns and hence it makes sense to try and keep
>the data they're working with in cache and hence temporal clustering is
>important.  As soon as you're dealing with queues of messages you've got
>two new problems, the temporal clustering is broken and even if not you
>got even more cache pressure and data-dependent operations.
>
>
>--
>  Sam  http://samason.me.uk/
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk