Gregory Haskins wrote:
virtio is already non-kvm-specific (lguest uses it) and
non-pci-specific (s390 uses it).
Ok, then to be more specific, I need it to be more generic than it
already is. For instance, I need it to be able to integrate with
shm_signals.
Why?
If you have a good exit mitigation scheme you can cut exits by a
factor of 100; so the userspace exit costs are cut by the same
factor. If you have good copyless networking APIs you can cut the
cost of copies to zero (well, to the cost of get_user_pages_fast(),
but a kernel solution needs that too).
"exit mitigation' schemes are for bandwidth, not latency. For latency
it all comes down to how fast you can signal in both directions. If
someone is going to do a stand-alone request-reply, its generally always
going to be at least one hypercall and one rx-interrupt. So your speed
will be governed by your signal path, not your buffer bandwidth.
The userspace path is longer by 2 microseconds (for two additional
heavyweight exits) and a few syscalls. I don't think that's worthy of
putting all the code in the kernel.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
