On Wed, Mar 03, 2010 at 08:15:15AM -0600, Anthony Liguori wrote: > On 03/02/2010 04:41 PM, Paul Brook wrote: > >>The new function I'm proposing has the following semantics: > >> > >>- it always returns a persistent mapping > >>- it never bounces > >>- it will only fail if the mapping isn't ram > >So you're assuming that virtio rings are in ram that is not hot-pluggable > > As long as the device is active, yes. This would be true with bare > metal. Memory allocated for the virtio-pci ring is not reclaimable > and you have to be able to reclaim the entire area of ram covered by > a DIMM to hot unplug it. A user would have to unload the virtio-pci > module to release the memory before hot unplug would be an option. > > NB, almost nothing supports memory hot remove because it's very > difficult for an OS to actually do. > > > or > >remapable, > > Yes, it cannot be remapable. > > > and the whole region is contiguous? > > Yes, it has to be contiguous. > > >That sounds like it's likely to come back and bite you. The guest has no idea > >which areas of ram happen to be contiguous on the host. > > Practically speaking, with target-i386 anything that is contiguous > in guest physical memory is contiguous in the host address space > provided it's ram. > > These assumptions are important. I have a local branch (that I'll > send out soon) that implements a ram API and converted virtio to > make use of it. I'm seeing a ~50% increase in tx throughput. > > If you try to support discontiguous, remapable ram for the virtio > ring, then you have to do an l1_phys_map lookup for every single > ring variable access followed by a memory copy. This ends up > costing an awful lot practically speaking.
Speed up the lookup instead? > > The changes should work equally well with syborg although I don't > think I can do meaningful performance testing there (I don't > actually have a syborg image to test). > > Regards, > > Anthony Liguori > > >Paul