Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

[Dong Jia <bjsdjshi@linux.vnet.ibm.com>]

On Fri, 13 May 2016 02:05:01 -0700
Neo Jia <cjia@nvidia.com> wrote:

...snip...

> 
> Hi Dong,
> 
> We should definitely be mindful about the data structure performance especially
> dealing with kernel. But for now, we haven't done any performance analysis yet
> for the current rbtree implementation, later we will definitely run it through
> large guest RAM configuration and multiple virtual devices cases, etc. to
> collect data.
> 
> Regarding your use case, may I ask if there will be concurrent command streams
> running for the same VM?
Hi Neo:

Sorry for the late response. Spent some time to make the confirmation.

For our case, one iommu group will add one (and only one) ccw-device.
For one ccw-device, there will be no concurrent command streams from it.

> If yes, those two transaction requests (if we
> implement) will compete not only the rbtree lock but also the GUP locks.
Since the answer is 'no, I guess we needn't do this. :>

> 
> Also, what is the typical guest RAM we are talking about here for your usecase
> and any rough estimation of the active working set of those DMA pages? 
> 
I'm afraid there is no typical guest RAM for the I/O instructions
issued by the passed-through ccw-device drivers. They can use any
memory chunk allocated by a kmalloc.

The working set depends on how much memory used by the device drivers,
and of course the number of the available memory. Since there is no
restrictions of the memory usage for this case, it varies...

[...]

--------
Dong Jia