On Fri, Nov 25, 2016 at 05:38:26PM +1100, Alexey Kardashevskiy wrote: > On 25/11/16 15:39, David Gibson wrote: > > On Thu, Nov 24, 2016 at 04:48:08PM +1100, Alexey Kardashevskiy wrote: > >> We are going to allow the userspace to configure container in > >> one memory context and pass container fd to another so > >> we are postponing memory allocations accounted against > >> the locked memory limit. One of previous patches took care of > >> it_userspace. > >> > >> At the moment we create the default DMA window when the first group is > >> attached to a container; this is done for the userspace which is not > >> DDW-aware but familiar with the SPAPR TCE IOMMU v2 in the part of memory > >> pre-registration - such client expects the default DMA window to exist. > >> > >> This postpones the default DMA window allocation till one of > >> the folliwing happens: > >> 1. first map/unmap request arrives; > >> 2. new window is requested; > >> This adds noop for the case when the userspace requested removal > >> of the default window which has not been created yet. > >> > >> Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxxxx> > > > > Hmm.. it just occurred to me: why do you even need to delay creation > > of the default window? > > > Because I want to account the memory it uses in locked_vm of the mm which > will later be used for map/unmap. Ah, good point. How is the locked vm accounted for the non ddw case. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
