Figure 8: Receive-side notification overhead breakdowns
In VMMC, messages are deposited directly into the memory of the receiving process without interrupting the host processor. The receiving process can detect message arrival by polling memory locations. But it can also use the VMMC notification mechanism to reduce the CPU polling overhead. For instance, the sockets library uses notifications extensively to avoid polling while waiting for data to arrive on a socket.
The VMMC notification mechanism allows a receiving process to associate a message handler with each exported buffer. The message handler is executed when a message with notification request arrives on the exported buffer. Since interrupts are used to deliver notifications to the corresponding process, different OS platforms show different performance.
Figure 8 shows the breakdown of the notification
overhead on the receiving machine. The interrupt cost is the time from
when the network interface issues the interrupt to the time when the
interrupt handler in the driver starts to execute.
Surprisingly
, both Linux and
NT take about 10 
s to reach the handler on our test platform. Once
interrupted, Linux uses 17 s to schedule the user level message
handler through the process signal mechanism. On NT, because
there are restrictions on what can be executed in the interrupt
handler, the interrupt handler has to queue a Deferred Procedure
Call(DPC) in the kernel which invokes the user-level notification
handler later. By the time the control reaches the start of the DPC
handler, 18 s has already passed. After this, NT uses 16 s to
schedule the user level message handler by waking up the user thread
that executes the message handler. Once the notification handler
terminates, Linux uses 3 s to return to the interrupted process
while NT uses 7 s to switch back to the interrupted
thread. The overall overhead for notification is 30 s on linux and
52 s on NT.