Message ID | 20210203003134.2422308-2-surenb@google.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1l7660-008PTQ-Np; Wed, 03 Feb 2021 00:32:38 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232457AbhBCAcV (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Tue, 2 Feb 2021 19:32:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232329AbhBCAcT (ORCPT <rfc822;linux-media@vger.kernel.org>); Tue, 2 Feb 2021 19:32:19 -0500 Received: from mail-qt1-x849.google.com (mail-qt1-x849.google.com [IPv6:2607:f8b0:4864:20::849]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE00EC0613ED for <linux-media@vger.kernel.org>; Tue, 2 Feb 2021 16:31:38 -0800 (PST) Received: by mail-qt1-x849.google.com with SMTP id v65so13332004qtd.0 for <linux-media@vger.kernel.org>; Tue, 02 Feb 2021 16:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=5KtTzd9k+c9bS2Y/wk34+i/vvyNbysJG7UZJv8N2Wp4=; b=oNXRZrunpy+nJxCNVG2DVespyvOU6v+/PBcSm/lmaxwIlZyPY+Y+aGI83iN/QE12TQ /9B5j+GzglaY+R0ZfttfhxpqWqSdb8Mhk5fb+2BB6mUU3pAKYZ4YkOotTy5PPFko52Yw DjiUxnZm5/e875fNSMeJZUpfPmcgyFUAHmh7OGgzKQMnmFkSDTyR+23aDUO7XbQpLyJ/ ODLwOmX6057PVKLp4hTX/hoK0O+U8lfiVVL2hxkockdBfgWJvRtI34i+fdKn9nJsjv6I DrqX9S8rzdrQ6xlTKqKv6sGUpn32curAQw3IMOe9YcnA/sGJg2xlAFdtgblXQs264SLf TFKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=5KtTzd9k+c9bS2Y/wk34+i/vvyNbysJG7UZJv8N2Wp4=; b=toea45MkEbnnAGNeAY0zbLpy9oZ8rTcs6e+SbczCiBPmznwkiv0ix8oTqPAES/ggRC wR63Z8CF8Kt17eWMEe9dVate+C98ANljdE0em2E2/pc3TUzB/T8F0vOJBSDn31TAHrtK 56nS9hdfyrmwPxYL+p0xr60e9uUhl4gZXP/Db+7zLBRIiMstcwvJhxBBs4sxVP/yWaZY a6F8mha6OwhWABlQbRtWIFIuSexdh5dIJxJMKMMpBc6M/FRSY4txLgjJtgW5ckJcB/ti QVNxjnAATN/DfiMrJwZ/N3mnlONhjO94wxPkyf/JlxyI0WBndA/pk6eAYKSKCtnYO5j6 E0SA== X-Gm-Message-State: AOAM532ZUW41CKlettel8DQgd2jM9hqdsa2rpFyshHkffSYQIt1UShMM 2qutlANTwXITaHF9JlRaplYfBQekmG8= X-Google-Smtp-Source: ABdhPJwlIrpFiCM10hcfIL1xRHkC2ka4Rp5OqMsb623obcfa1dzEsxG62HhtetSAvxKOVvEOcxKdtwB6Ytc= Sender: "surenb via sendgmr" <surenb@surenb1.mtv.corp.google.com> X-Received: from surenb1.mtv.corp.google.com ([2620:15c:211:200:9194:cd6:1ec:3e2d]) (user=surenb job=sendgmr) by 2002:a0c:8365:: with SMTP id j92mr418503qva.19.1612312297983; Tue, 02 Feb 2021 16:31:37 -0800 (PST) Date: Tue, 2 Feb 2021 16:31:34 -0800 In-Reply-To: <20210203003134.2422308-1-surenb@google.com> Message-Id: <20210203003134.2422308-2-surenb@google.com> Mime-Version: 1.0 References: <20210203003134.2422308-1-surenb@google.com> X-Mailer: git-send-email 2.30.0.365.g02bc693789-goog Subject: [PATCH v2 2/2] dma-buf: heaps: Map system heap pages as managed by linux vm From: Suren Baghdasaryan <surenb@google.com> To: sumit.semwal@linaro.org Cc: akpm@linux-foundation.org, hch@infradead.org, lmark@codeaurora.org, labbott@redhat.com, Brian.Starkey@arm.com, john.stultz@linaro.org, christian.koenig@amd.com, cgoldswo@codeaurora.org, orjan.eide@arm.com, robin.murphy@arm.com, jajones@nvidia.com, minchan@kernel.org, hridya@google.com, sspatil@google.com, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com, surenb@google.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -10.0 (----------) X-LSpam-Report: No, score=-10.0 required=5.0 tests=BAYES_00=-1.9,DKIMWL_WL_MED=0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,USER_IN_DEF_DKIM_WL=-7.5 autolearn=ham autolearn_force=no |
Series |
[1/2] mm: replace BUG_ON in vm_insert_page with a return of an error
|
|
Commit Message
Suren Baghdasaryan
Feb. 3, 2021, 12:31 a.m. UTC
Currently system heap maps its buffers with VM_PFNMAP flag using
remap_pfn_range. This results in such buffers not being accounted
for in PSS calculations because vm treats this memory as having no
page structs. Without page structs there are no counters representing
how many processes are mapping a page and therefore PSS calculation
is impossible.
Historically, ION driver used to map its buffers as VM_PFNMAP areas
due to memory carveouts that did not have page structs [1]. That
is not the case anymore and it seems there was desire to move away
from remap_pfn_range [2].
Dmabuf system heap design inherits this ION behavior and maps its
pages using remap_pfn_range even though allocated pages are backed
by page structs.
Replace remap_pfn_range with vm_insert_page, following Laura's suggestion
in [1]. This would allow correct PSS calculation for dmabufs.
[1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io
[2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html
(sorry, could not find lore links for these discussions)
Suggested-by: Laura Abbott <labbott@kernel.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
v1 posted at: https://lore.kernel.org/patchwork/patch/1372409/
changes in v2:
- removed VM_PFNMAP clearing part of the patch, per Minchan and Christoph
- created prerequisite patch to replace BUG_ON with WARN_ON_ONCE, per Christoph
drivers/dma-buf/heaps/system_heap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote: > Currently system heap maps its buffers with VM_PFNMAP flag using > remap_pfn_range. This results in such buffers not being accounted > for in PSS calculations because vm treats this memory as having no > page structs. Without page structs there are no counters representing > how many processes are mapping a page and therefore PSS calculation > is impossible. > Historically, ION driver used to map its buffers as VM_PFNMAP areas > due to memory carveouts that did not have page structs [1]. That > is not the case anymore and it seems there was desire to move away > from remap_pfn_range [2]. > Dmabuf system heap design inherits this ION behavior and maps its > pages using remap_pfn_range even though allocated pages are backed > by page structs. > Replace remap_pfn_range with vm_insert_page, following Laura's suggestion > in [1]. This would allow correct PSS calculation for dmabufs. > > [1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io > [2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html > (sorry, could not find lore links for these discussions) > > Suggested-by: Laura Abbott <labbott@kernel.org> > Signed-off-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Minchan Kim <minchan@kernel.org> A note: This patch makes dmabuf system heap accounted as PSS so if someone has relies on the size, they will see the bloat. IIRC, there was some debate whether PSS accounting for their buffer is correct or not. If it'd be a problem, we need to discuss how to solve it(maybe, vma->vm_flags and reintroduce remap_pfn_range for them to be respected).
On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim <minchan@kernel.org> wrote: > > On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote: > > Currently system heap maps its buffers with VM_PFNMAP flag using > > remap_pfn_range. This results in such buffers not being accounted > > for in PSS calculations because vm treats this memory as having no > > page structs. Without page structs there are no counters representing > > how many processes are mapping a page and therefore PSS calculation > > is impossible. > > Historically, ION driver used to map its buffers as VM_PFNMAP areas > > due to memory carveouts that did not have page structs [1]. That > > is not the case anymore and it seems there was desire to move away > > from remap_pfn_range [2]. > > Dmabuf system heap design inherits this ION behavior and maps its > > pages using remap_pfn_range even though allocated pages are backed > > by page structs. > > Replace remap_pfn_range with vm_insert_page, following Laura's suggestion > > in [1]. This would allow correct PSS calculation for dmabufs. > > > > [1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io > > [2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html > > (sorry, could not find lore links for these discussions) > > > > Suggested-by: Laura Abbott <labbott@kernel.org> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > Reviewed-by: Minchan Kim <minchan@kernel.org> > > A note: This patch makes dmabuf system heap accounted as PSS so > if someone has relies on the size, they will see the bloat. > IIRC, there was some debate whether PSS accounting for their > buffer is correct or not. If it'd be a problem, we need to > discuss how to solve it(maybe, vma->vm_flags and reintroduce > remap_pfn_range for them to be respected). I did not see debates about not including *mapped* dmabufs into PSS calculation. I remember people were discussing how to account dmabufs referred only by the FD but that is a different discussion. If the buffer is mapped into the address space of a process then IMHO including it into PSS of that process is not controversial.
On Tue, Feb 2, 2021 at 4:31 PM Suren Baghdasaryan <surenb@google.com> wrote: > Currently system heap maps its buffers with VM_PFNMAP flag using > remap_pfn_range. This results in such buffers not being accounted > for in PSS calculations because vm treats this memory as having no > page structs. Without page structs there are no counters representing > how many processes are mapping a page and therefore PSS calculation > is impossible. > Historically, ION driver used to map its buffers as VM_PFNMAP areas > due to memory carveouts that did not have page structs [1]. That > is not the case anymore and it seems there was desire to move away > from remap_pfn_range [2]. > Dmabuf system heap design inherits this ION behavior and maps its > pages using remap_pfn_range even though allocated pages are backed > by page structs. > Replace remap_pfn_range with vm_insert_page, following Laura's suggestion > in [1]. This would allow correct PSS calculation for dmabufs. > > [1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io > [2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html > (sorry, could not find lore links for these discussions) > > Suggested-by: Laura Abbott <labbott@kernel.org> > Signed-off-by: Suren Baghdasaryan <surenb@google.com> For consistency, do we need something similar for the cma heap as well? thanks -john
On Tue, Feb 2, 2021 at 6:07 PM John Stultz <john.stultz@linaro.org> wrote: > > On Tue, Feb 2, 2021 at 4:31 PM Suren Baghdasaryan <surenb@google.com> wrote: > > Currently system heap maps its buffers with VM_PFNMAP flag using > > remap_pfn_range. This results in such buffers not being accounted > > for in PSS calculations because vm treats this memory as having no > > page structs. Without page structs there are no counters representing > > how many processes are mapping a page and therefore PSS calculation > > is impossible. > > Historically, ION driver used to map its buffers as VM_PFNMAP areas > > due to memory carveouts that did not have page structs [1]. That > > is not the case anymore and it seems there was desire to move away > > from remap_pfn_range [2]. > > Dmabuf system heap design inherits this ION behavior and maps its > > pages using remap_pfn_range even though allocated pages are backed > > by page structs. > > Replace remap_pfn_range with vm_insert_page, following Laura's suggestion > > in [1]. This would allow correct PSS calculation for dmabufs. > > > > [1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-memory-for-direct-io > > [2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-October/127519.html > > (sorry, could not find lore links for these discussions) > > > > Suggested-by: Laura Abbott <labbott@kernel.org> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > For consistency, do we need something similar for the cma heap as well? Good question. Let me look closer into it. > > thanks > -john
Am 03.02.21 um 03:02 schrieb Suren Baghdasaryan: > On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim <minchan@kernel.org> wrote: >> On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote: >>> Currently system heap maps its buffers with VM_PFNMAP flag using >>> remap_pfn_range. This results in such buffers not being accounted >>> for in PSS calculations because vm treats this memory as having no >>> page structs. Without page structs there are no counters representing >>> how many processes are mapping a page and therefore PSS calculation >>> is impossible. >>> Historically, ION driver used to map its buffers as VM_PFNMAP areas >>> due to memory carveouts that did not have page structs [1]. That >>> is not the case anymore and it seems there was desire to move away >>> from remap_pfn_range [2]. >>> Dmabuf system heap design inherits this ION behavior and maps its >>> pages using remap_pfn_range even though allocated pages are backed >>> by page structs. >>> Replace remap_pfn_range with vm_insert_page, following Laura's suggestion >>> in [1]. This would allow correct PSS calculation for dmabufs. >>> >>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdriverdev-devel.linuxdriverproject.narkive.com%2Fv0fJGpaD%2Fusing-ion-memory-for-direct-io&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb4c145b86dd0472c943c08d8c7e7ba4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479145389160353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W1N%2B%2BlcFDaRSvXdSPe5hPNMRByHfGkU7Uc3cmM3FCTU%3D&reserved=0 >>> [2] https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverdev.linuxdriverproject.org%2Fpipermail%2Fdriverdev-devel%2F2018-October%2F127519.html&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb4c145b86dd0472c943c08d8c7e7ba4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479145389160353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jQxSzKEr52lUcAIx%2FuBHMJ7yOgof%2FVMlW9%2BB2f%2FoS%2FE%3D&reserved=0 >>> (sorry, could not find lore links for these discussions) >>> >>> Suggested-by: Laura Abbott <labbott@kernel.org> >>> Signed-off-by: Suren Baghdasaryan <surenb@google.com> >> Reviewed-by: Minchan Kim <minchan@kernel.org> >> >> A note: This patch makes dmabuf system heap accounted as PSS so >> if someone has relies on the size, they will see the bloat. >> IIRC, there was some debate whether PSS accounting for their >> buffer is correct or not. If it'd be a problem, we need to >> discuss how to solve it(maybe, vma->vm_flags and reintroduce >> remap_pfn_range for them to be respected). > I did not see debates about not including *mapped* dmabufs into PSS > calculation. I remember people were discussing how to account dmabufs > referred only by the FD but that is a different discussion. If the > buffer is mapped into the address space of a process then IMHO > including it into PSS of that process is not controversial. Well, I think it is. And to be honest this doesn't looks like a good idea to me since it will eventually lead to double accounting of system heap DMA-bufs. As discussed multiple times it is illegal to use the struct page of a DMA-buf. This case here is a bit special since it is the owner of the pages which does that, but I'm not sure if this won't cause problems elsewhere as well. A more appropriate solution would be to held processes accountable for resources they have allocated through device drivers. Regards, Christian.
On Wed, Feb 3, 2021 at 12:06 AM Christian König <christian.koenig@amd.com> wrote: > > Am 03.02.21 um 03:02 schrieb Suren Baghdasaryan: > > On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim <minchan@kernel.org> wrote: > >> On Tue, Feb 02, 2021 at 04:31:34PM -0800, Suren Baghdasaryan wrote: > >>> Currently system heap maps its buffers with VM_PFNMAP flag using > >>> remap_pfn_range. This results in such buffers not being accounted > >>> for in PSS calculations because vm treats this memory as having no > >>> page structs. Without page structs there are no counters representing > >>> how many processes are mapping a page and therefore PSS calculation > >>> is impossible. > >>> Historically, ION driver used to map its buffers as VM_PFNMAP areas > >>> due to memory carveouts that did not have page structs [1]. That > >>> is not the case anymore and it seems there was desire to move away > >>> from remap_pfn_range [2]. > >>> Dmabuf system heap design inherits this ION behavior and maps its > >>> pages using remap_pfn_range even though allocated pages are backed > >>> by page structs. > >>> Replace remap_pfn_range with vm_insert_page, following Laura's suggestion > >>> in [1]. This would allow correct PSS calculation for dmabufs. > >>> > >>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdriverdev-devel.linuxdriverproject.narkive.com%2Fv0fJGpaD%2Fusing-ion-memory-for-direct-io&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb4c145b86dd0472c943c08d8c7e7ba4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479145389160353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W1N%2B%2BlcFDaRSvXdSPe5hPNMRByHfGkU7Uc3cmM3FCTU%3D&reserved=0 > >>> [2] https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverdev.linuxdriverproject.org%2Fpipermail%2Fdriverdev-devel%2F2018-October%2F127519.html&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb4c145b86dd0472c943c08d8c7e7ba4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479145389160353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jQxSzKEr52lUcAIx%2FuBHMJ7yOgof%2FVMlW9%2BB2f%2FoS%2FE%3D&reserved=0 > >>> (sorry, could not find lore links for these discussions) > >>> > >>> Suggested-by: Laura Abbott <labbott@kernel.org> > >>> Signed-off-by: Suren Baghdasaryan <surenb@google.com> > >> Reviewed-by: Minchan Kim <minchan@kernel.org> > >> > >> A note: This patch makes dmabuf system heap accounted as PSS so > >> if someone has relies on the size, they will see the bloat. > >> IIRC, there was some debate whether PSS accounting for their > >> buffer is correct or not. If it'd be a problem, we need to > >> discuss how to solve it(maybe, vma->vm_flags and reintroduce > >> remap_pfn_range for them to be respected). > > I did not see debates about not including *mapped* dmabufs into PSS > > calculation. I remember people were discussing how to account dmabufs > > referred only by the FD but that is a different discussion. If the > > buffer is mapped into the address space of a process then IMHO > > including it into PSS of that process is not controversial. > > Well, I think it is. And to be honest this doesn't looks like a good > idea to me since it will eventually lead to double accounting of system > heap DMA-bufs. Thanks for the comment! Could you please expand on this double accounting issue? Do you mean userspace could double account dmabufs because it expects dmabufs not to be part of PSS or is there some in-kernel accounting mechanism that would be broken by this? > > As discussed multiple times it is illegal to use the struct page of a > DMA-buf. This case here is a bit special since it is the owner of the > pages which does that, but I'm not sure if this won't cause problems > elsewhere as well. I would be happy to keep things as they are but calculating dmabuf contribution to PSS without struct pages is extremely inefficient and becomes a real pain when we consider the possibilities of partial mappings, when not the entire dmabuf is being mapped. Calculating this would require parsing /proc/pid/maps for the process, finding dmabuf mappings and the size for each one, then parsing /proc/pid/maps for ALL processes in the system to see if the same dmabufs are used by other processes and only then calculating the PSS. I hope that explains the desire to use already existing struct pages to obtain PSS in a much more efficient way. > > A more appropriate solution would be to held processes accountable for > resources they have allocated through device drivers. Are you suggesting some new kernel mechanism to account resources allocated by a process via a driver? If so, any details? > > Regards, > Christian. > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >
diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 17e0e9a68baf..4983f18cc2ce 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -203,8 +203,7 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) for_each_sgtable_page(table, &piter, vma->vm_pgoff) { struct page *page = sg_page_iter_page(&piter); - ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE, - vma->vm_page_prot); + ret = vm_insert_page(vma, addr, page); if (ret) return ret; addr += PAGE_SIZE;