nadiasvertex at gmail.com
Tue May 22 14:12:54 EDT 2007
On 5/22/07, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> On Tue, 2007-05-22 at 13:23 -0400, Christopher Nelson wrote:
> > > It also seems like it could induce false sharing between
> > independent
> > > threads and processes, where delays in fault handling by
> > other threads
> > > or processes could cause those to propagate and slow down
> > groups who's
> > > processing is otherwise unrelated. Of course, this assumes
> > that you
> > > are using these handlers for various types of notification
> > (like
> > > memory mapping / etc.)
> > Now that it is clearer how the fault handler works, do you
> > still have
> > this concern?
> > No. It seems that the only concern I would still have is that
> > external fault handlers seem very heavy in comparison to activation
> > handlers. Therefore, you are in a space/complexity trade-off. If
> > these critical paths that activation handlers are blocking are so
> > systemically significant that using external fault handlers will
> > provide a boost sufficient to negate the memory overhead - then I say
> > go for it.
> 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)
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). The handler performs some
operations, and then when the function of the handler returns, context is
restored w/o any ring transitions.
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. 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coyotos-dev