[coyotos-dev] IPC redesign issues, goals, and options

Jonathan S. Shapiro shap at eros-os.com
Tue Feb 13 18:56:45 CST 2007


This won't perform well. The point of using pages is that the page
capability can be pre-cached in the FCRB and re-used, so that the
address space traversal is not needed. Your proposal would require
address space traversal on every receive, and it breaks the exception
model if a short message requires this.

It's a good idea, but this is a difficult design space.

shap

On Tue, 2007-02-13 at 23:20 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 13/02/2007 hora 10:19:
> > 4. Move to a design where the payload currently stored in the FCRB is
> > delivered immediately, but not to registers. In this design, the FCRB
> > contains two capabilities: [...]
> >
> > This is doable, but it is space intensive. Every outstanding receive
> > now ties down *two* pages, which is an even bigger problem on small
> > memory systems.
> 
> In all cases where registers are replaced by pages, and where this adds
> this space problem, I wonder if they couldn't be replaced by ranges to
> pages. That is, if a process knows it will only receive two capabilities
> in an FCRB reply, it can make the capability reply range point to
> 
> 	(someCapPage, someOffset, someOffset + 1)
> 
> IIUC, this enables the process to make that point to the capability
> registers if speed is really needed.
> 
> Curiously,
> Pierre
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev



More information about the coyotos-dev mailing list