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=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 66419C433E0 for ; Wed, 3 Feb 2021 02:14:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18A4964F4A for ; Wed, 3 Feb 2021 02:14:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231635AbhBCCOY (ORCPT ); Tue, 2 Feb 2021 21:14:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229889AbhBCCOT (ORCPT ); Tue, 2 Feb 2021 21:14:19 -0500 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F23E7C061573 for ; Tue, 2 Feb 2021 18:13:38 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id d16so22416618wro.11 for ; Tue, 02 Feb 2021 18:13:38 -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=+vYDps8/+IhHaSDG5kMjkWUxFJUq2DFUOYgi2VmWXtI=; b=QT34eaYNV8fBLXWs/JBogWNBxvdF8ywloFrclidxZLbMY42rIDA48Y8pWRzaRg5kyn cJA/Pz4LjH28NykDdh27Y+YDF2VA1ob27B9AmZ+b+y8eFiRD3fKog+kSs9ztUIQwluk5 G5LsE1Hmui8HoXHVY8szdjd48rhhZA4JUPeSSoXEZMxzn3bocg+h4SnDsxruSuxRv9QT bTpIhgtjAyR+m3tKilxDCcEYtYANNdJ3CrpkPwfxvl9JzsXtY4jEpaPrHe4emg1kiNRY Tub23wpwxyjLb6730Xg39sU0NDx1RWY4HzKlBzNT+btC4Ta9Vj6gI7TYaH3+g8P5rtUU HPRA== 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=+vYDps8/+IhHaSDG5kMjkWUxFJUq2DFUOYgi2VmWXtI=; b=PCKujtzXexMWrbmNvIbNpBLI6xz89Zx93GU2CpMSjZHPIPn3MsDuVLU2RadpWy0PvW seF4Jk4r1GOJy0Pz7zTLgTb+/Rv/RZvTzNIIrlTBYDCe1rmNo3zBT/uDGUTJ0oxqvDxH fHiIO/7GVM2uG9Hgna7XmOHs11Xjir94VzfHt7cIha0RSi/SC2A5NfvVMSCrvcAH090p 1MtegE6rSLbb5W+S5Scm9q4WYtQeuRL1bw7/4qYudbdJTzj3E8ITbBM6mogixOn606eY mFQ5Nh0JUh1WBJHweqyN+C2nEqI+vmQ/rbdZBabRZ3TstmI7p1AppfcNXiqItg52DJrv VcyA== X-Gm-Message-State: AOAM533BGfSEt3ydPbrHBPOtqt9vEDdydSfr4Ew7hOMVahouTQLWl7Kv TfCcNxhvbrIac0PC6MkavnHCcv4VbearUkMfng4BWA== X-Google-Smtp-Source: ABdhPJzwvb53VryiSIObA9yOm78VKVx2cE/HoZ+IGvTixGvWum4punD5XJ9toA2haG1k35oBs/GNn0NjBEvmjKg7phM= X-Received: by 2002:a5d:453b:: with SMTP id j27mr895948wra.92.1612318417595; Tue, 02 Feb 2021 18:13:37 -0800 (PST) MIME-Version: 1.0 References: <20210203003134.2422308-1-surenb@google.com> <20210203003134.2422308-2-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 2 Feb 2021 18:13:26 -0800 Message-ID: Subject: Re: [PATCH v2 2/2] dma-buf: heaps: Map system heap pages as managed by linux vm To: John Stultz Cc: Sumit Semwal , Andrew Morton , Christoph Hellwig , Liam Mark , Laura Abbott , Brian Starkey , Christian Koenig , Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , James Jones , Minchan Kim , Hridya Valsaraju , Sandeep Patil , linux-media , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , linux-mm , lkml , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2021 at 6:07 PM John Stultz wrote: > > On Tue, Feb 2, 2021 at 4:31 PM 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 > > Signed-off-by: Suren Baghdasaryan > > For consistency, do we need something similar for the cma heap as well? Good question. Let me look closer into it. > > thanks > -john