Re: [PATCH V1 vfio 0/6] Move to use cgroups for userspace persistent allocations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 18 Jan 2023 11:15:07 -0400
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:

> On Tue, Jan 17, 2023 at 04:38:11PM -0700, Alex Williamson wrote:
> 
> > The type1 IOMMU backend is notably absent here among the core files, any
> > reason?  
> 
> Mostly fear that charging alot of memory to the cgroup will become a
> compatibility problem. I'd be happier if we go along the iommufd path
> some more and get some field results from cgroup enablement before we
> think about tackling type 1.
> 
> With this series in normal non-abusive cases this is probably only a
> few pages of ram so it shouldn't be a problem. mlx5 needs huge amounts
> of memory but it is new so anyone deploying a new mlx5 configuration
> can set their cgroup accordingly.
> 
> If we fully do type 1 we are looking at alot of memory. eg a 1TB
> guest will charge 2GB just in IOPTE structures at 4k page size. Maybe
> that is enough to be a problem, I don't know.
> 
> > Potentially this removes the dma_avail issue as a means to
> > prevent userspace from creating an arbitrarily large number of DMA
> > mappings, right?  
> 
> Yes, it is what iommufd did
>  
> > Are there any compatibility issues we should expect with this change to
> > accounting otherwise?  
> 
> Other than things might start hitting the limit, I don't think so?

Ok, seems like enough FUD to limit the scope for now.  We'll need to
monitor this for native and compat mode iommufd use.  I'll fix the
commit log typo, assuming there are no further comments.  Thanks,

Alex




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux