[coyotos-dev] Activations

[Jonathan S. Shapiro]

On Tue, 2007-05-22 at 14:12 -0400, Christopher Nelson wrote:

>         
>         Umm. Chris? The memory overhead of the activation handler is
>         actually
>         *higher* than the memory overhead of the external handler... 
> 
> Seriously? Then I have a misunderstanding about activation handlers.
> My impression of their function was like this:
> 
> MMAP - 1 per process (1 total)
> Stack   - 1 per thread   (N total for N threads) 

Not sure what you mean by MMAP here. Can you expand?

> 
> On dispatch, the kernel pauses the thread, stores it's context just
> like any other switch.  Then activates the handler in place. (ie it
> operates on the same stack in the same address space). 

Same space, but not the same stack. You can't assume that the
application stack is in a sane state, and one of the things you might be
dealing with in the activation handler is the need to fix a page fault
that occurred in the application stack region.

>  The handler performs some operations, and then when the function of
> the handler returns, context is restored w/o any ring transitions. 

True in most activation schemes, but not true in Coyotos, because you
need to restore the capability registers, and this requires a ring
transition.

Recall when comparing that there are two independent issues here:

  1. The cost of the U->S->U transition
  2. The cost of the address space switch

When people quote cswitch times, they generally lump these together. Of
the two, the address space switch is the dominant cost. In EROS and
Coyotos, we don't incur that cost if the invoker and invokee share the
same address space.

Part of the attraction of activation handlers derives from the fact that
(a) the cswitch term is widely misconstrued, and (b) most OS's assume
that distinct processes do not share address spaces, and therefore do
not attempt to optimize out the address space switch.

> My understanding of extern fault handlers is:
> 
> MMAP - 1 per process (2 total (at minimum), 1 for the user process, 1
> for the external fault handler)
> Stack  - 1 per thread    (2 total) (at minimum), 1 for the user
> process's main thread, 1 for the external fault handler) 
> 
> On dispatch, the user process is paused, the fault handler is
> activated, the fault is cared for, then the user process is generally
> resumed.
> 
> With this understanding it seems like external fault handlers are
> twice as expensive in every way as activation schedulers.

Hopefully, it is now clearer that the issue isn't quite that black and
white. There is no difference in stack requirement. I'll hold on the
MMAP requirement until you explain what you mean by MMAP. I don't
imagine you are referring to the MMAP system call here, because no
memory mapping operations occur in either design.

>   I understand that you indicated there is some post-processing work
> that an activation handler has to do in order to complete it's work
> that requires another kernel invocation.  I trust that you are also
> indicating that an activation handler requires additional memory
> overhead as well? 

Yes. That is: your shared stack assumption is incorrect. It is a
feasible design, but it effectively precludes having the activation
handler be responsible for page faults. Since page faults are by far the
most common fault that a process incurs, that pretty much defeats
activation handlers.


shap