IPC

Higher-level IPC primitives

Pebble portals - to use in Metta, but not in Vesper

IPC makes use of portals - pieces of code, used as trampolines into the kernel to do the thread switch. These portals can be re-generated by the optimizing loader (OMOS) without giving up flexibility and protection but gaining additional speed by optimizing generic things like thread_self() call which can be done completely in userspace.

• One-way
• Idempotent
• Reliable

---

[lrpc.pdf]

Multiple processors are used to reduce LRPC latency by caching domain contexts on idle processors. As we show in Section 4, the context switch that occurs during an LRPC is responsible for a large part of the transfer time. This time is due partly to the code required to update the hardware’s virtual memory registers and partly to the extra memory fetches that occur as a result of invalidating the translation lookaside buffer (TLB).

LRPC reduces context-switch overhead by caching domains on idle processors. When a call is made, the kernel checks for a processor idling in the context of the server domain. If one is found, the kernel exchanges the processors of the calling and idling threads, placing the calling thread on a processor where the context of the server domain is already loaded; the called server procedure can then execute on that processor without requiring a context switch. The idling thread continues to idle, but on the client’s original processor in the context of the client domain. On return from the server, a check is also made. If a processor is idling in the client domain (likely for calls that return quickly), then the processor exchange can be done again.

Fluke

Utah-Mach. [Ford and Lepreau 1994, thread-migrate.pdf] changed Mach IPC semantics to migrating RPC which is based on thread migration between address spaces, similar to the ''Clouds model [Bernabeu-Auban et al. 1988].'' Substantial performance gain was achieved, a factor of 3 to 4.