From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F37FC433E0 for ; Thu, 28 Jan 2021 17:55:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 53B0E64E15 for ; Thu, 28 Jan 2021 17:55:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231360AbhA1RzG (ORCPT ); Thu, 28 Jan 2021 12:55:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231173AbhA1RyK (ORCPT ); Thu, 28 Jan 2021 12:54:10 -0500 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D163EC06121F for ; Thu, 28 Jan 2021 09:53:11 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id c4so3601583wru.9 for ; Thu, 28 Jan 2021 09:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1yrHTpCxJbPqJxPosBUCqHjQNeMsmt6Vm7ugtgzEReE=; b=ez3mBXPhoqFz1D3IFmXN3JtwjoO2rNSDfgvnHC2YcXG14lhpNPd5zYmbbD8+pcGVq6 AI2c8Urh2Bb+okX+xWbE5YxfBXEvjwaAH4ag9VriOmGaE8MLOma8D2W56hCwqfIun6A9 P133f7nV5kCBXDTJ0v3Fh7ufr+igEpbVcs2OxxVnfhcFOTm2VQ+2KOvcJxxtpe0eXIjO oNI6bg5v2vfU/OymKzVBb8jV6UyEZSlca/u9CCqCQh5CUMP8ej4gYQUhqkCY50a3Y75G aQyhYowhGe/6O6ZDgEv+PVFoYmQIdibb8orbwSm6/XmEH2wzsaKDo6c0p/HNCBl2BWKL eMig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1yrHTpCxJbPqJxPosBUCqHjQNeMsmt6Vm7ugtgzEReE=; b=cGHDosx3jYD9/GO2LMISveZVhQ/YEJTO+rRSxPy564QKSe84npBvCvZUOunZZE710A 8wZ7X+EazWbfs/qg37S+i3VYk+kizpyWSiLKggP5dCzYj/xNfyp/5xyaFKZs+b9DT5hu sjyr+xJsXyTYDiePgTnkbYnGQeFDX6VLo0SzQ+ceH1ql2fHbLE9FpB09T3ANvwBVbhvs njB9fbAMflDEEq1BnPKJoKU2MOFUHB+01jCOzXVlbXLUFZr+xw8gGr0mMU9ankDJWSAe o6pjNerJLLdJxLaiqLTZ9Fxil/6Ec/rgAuqRGJL6jE7zDFwKOeHGq7xBUwl8GPQCp8Lx wNVw== X-Gm-Message-State: AOAM532SHEwORs8nEfIm5R3oOlnWLhSBGZxuW4D0iVw8pyto0Qz87LjL SZJVTJRScEkRgU9zmGIDAFSWU1GJzJAHBjpqvSFEOQ== X-Google-Smtp-Source: ABdhPJxwJqmSpiOHWxbkktFlqp4IMoBe4w7eVr8q1PfPy4kMSqkddDUEO7do+MQxEcJmtNOrfxqEeXfGoH86SezSyCg= X-Received: by 2002:adf:ed45:: with SMTP id u5mr267262wro.358.1611856390338; Thu, 28 Jan 2021 09:53:10 -0800 (PST) MIME-Version: 1.0 References: <20210128083817.314315-1-surenb@google.com> <20210128091348.GA1962975@infradead.org> In-Reply-To: <20210128091348.GA1962975@infradead.org> From: Suren Baghdasaryan Date: Thu, 28 Jan 2021 09:52:59 -0800 Message-ID: Subject: Re: [PATCH 1/1] dma-buf: heaps: Map system heap pages as managed by linux vm To: Christoph Hellwig Cc: Sumit Semwal , benjamin.gaignard@linaro.org, Liam Mark , labbott@redhat.com, Brian Starkey , John Stultz , christian.koenig@amd.com, Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , James Jones , Minchan Kim , Hridya Valsaraju , Sandeep Patil , linux-media , DRI mailing list , "moderated list:DMA BUFFER SHARING FRAMEWORK" , LKML , kernel-team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2021 at 1:13 AM Christoph Hellwig wrote: > > On Thu, Jan 28, 2021 at 12:38:17AM -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. > > Clear VM_IO and VM_PFNMAP flags when mapping memory allocated by the > > system heap and 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 > > Signed-off-by: Suren Baghdasaryan > > --- > > drivers/dma-buf/heaps/system_heap.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > > index 17e0e9a68baf..0e92e42b2251 100644 > > --- a/drivers/dma-buf/heaps/system_heap.c > > +++ b/drivers/dma-buf/heaps/system_heap.c > > @@ -200,11 +200,13 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) > > struct sg_page_iter piter; > > int ret; > > > > + /* All pages are backed by a "struct page" */ > > + vma->vm_flags &= ~VM_PFNMAP; > > Why do we clear this flag? It shouldn't even be set here as far as I > can tell. Thanks for the question, Christoph. I tracked down that flag being set by drm_gem_mmap_obj() which DRM drivers use to "Set up the VMA to prepare mapping of the GEM object" (according to drm_gem_mmap_obj comments). I also see a pattern in several DMR drivers to call drm_gem_mmap_obj()/drm_gem_mmap(), then clear VM_PFNMAP and then map the VMA (for example here: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rockchip/rockchip_drm_gem.c#L246). I thought that dmabuf allocator (in this case the system heap) would be the right place to set these flags because it controls how memory is allocated before mapping. However it's quite possible that I'm missing the real reason for VM_PFNMAP being set in drm_gem_mmap_obj() before dma_buf_mmap() is called. I could not find the answer to that, so I hope someone here can clarify that.