Messages in this thread |  | | | Date | Thu, 02 Apr 2009 14:43:39 +0300 | | From | Avi Kivity <> | | Subject | Re: [RFC PATCH 00/17] virtual-bus |
| |
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
|  |