On 25/11/16 22:37, David Gibson wrote: > 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. When ioctl(ENABLE) is processed, the SPAPR TCE driver increments it. The DDW case does not use ENABLE, the memory preregistration is used instead. -- Alexey
Attachment:
signature.asc
Description: OpenPGP digital signature
