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=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 30227C433DB for ; Wed, 3 Feb 2021 02:02:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B17DA64F74 for ; Wed, 3 Feb 2021 02:02:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B17DA64F74 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 134A56B006E; Tue, 2 Feb 2021 21:02:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E6BA6B0070; Tue, 2 Feb 2021 21:02:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F18796B0071; Tue, 2 Feb 2021 21:02:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0079.hostedemail.com [216.40.44.79]) by kanga.kvack.org (Postfix) with ESMTP id DC8FD6B006E for ; Tue, 2 Feb 2021 21:02:15 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 992238249980 for ; Wed, 3 Feb 2021 02:02:15 +0000 (UTC) X-FDA: 77775306630.08.bag05_5f090a6275cf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 789E61819E76C for ; Wed, 3 Feb 2021 02:02:15 +0000 (UTC) X-HE-Tag: bag05_5f090a6275cf X-Filterd-Recvd-Size: 5666 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Feb 2021 02:02:14 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id q7so22414013wre.13 for ; Tue, 02 Feb 2021 18:02:14 -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=k1d6YTsPbefNP98n7kugOKyTm/5Jjwmgp6qDjgryobQ=; b=YTpxuQQ56VEKPyP5QRwFOXD5rzq90h+zb0bL5zaHyoZAGpubAhVDWr6tVquoLfUHXY 8Bgskv29OXx/jlR9EGtJIj2o0B36+WZncwc30a96duFnTOR6NIS20pOkUXRH1YLOzXjx rd796bWXm93rjoNLs5XewciYkKHyTn0eFOpN5IkEe8j0OFbNs/YrOetNsTJ6nmGccTFF ppqnrLaeHkAtN+jfTW3sILXbMs+y+eKWJtYUCP90lE6ejamVvj0wYtOVvAMo/jMCTtxl VNobZKCa1yOaQeNS8a2B0xxWxeuJgYXvbwrr101FjA/2VRquOyZZ58akT0yeyVEGoY5c ac0A== 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=k1d6YTsPbefNP98n7kugOKyTm/5Jjwmgp6qDjgryobQ=; b=aWhD3AReEVQ1O4zxBttL80AHLLxMeH9yrVaQY3NQqJrZ5tukGVLYN7KUca+Rf9eMxN 89pbWGpOGdXtDkKQtZkfo1GFvGh578+9RQqJZVYuT6tPRm8cLCL5aKPgoUSfdH9iI3Ga XknefUPJXS9udADjNiLej+Yfh13Dohp6G4yZE8OnEH2cUM+4LJnbYhO21ujSCKSE4aG/ Nk0jKIlr+lpPpZaRqXNxXyMPD03QJocHQ8dzQ82HQ17rNP67U4DyYFpmXVp56QrkrHZL oPUYyfNwO7xqAaqCtmPTcuHLiQsfwhBbbar4F9qra7vtq8Ub4GlaagObwO+rzsxhqjJ9 r90w== X-Gm-Message-State: AOAM533GKxyE2Yxh8Afjt3TM6VF6uMkHd/gPBYGhgtmhXfTTQr0qB3sm 3S1AoKX7e1TDGL68g0ErJy5r0GaO6M2idSUuMieNyA== X-Google-Smtp-Source: ABdhPJyQn6YddfkLVWiIGgY37mm6xAPU8tZAWB5sXAvWUT2z2eLAGdHnF+0pzujgGtm+uL0SK+Mb5ISJFicsxp8PRdg= X-Received: by 2002:adf:e50e:: with SMTP id j14mr860530wrm.162.1612317733369; Tue, 02 Feb 2021 18:02:13 -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:02:01 -0800 Message-ID: Subject: Re: [PATCH v2 2/2] dma-buf: heaps: Map system heap pages as managed by linux vm To: Minchan Kim Cc: Sumit Semwal , Andrew Morton , Christoph Hellwig , Liam Mark , labbott@redhat.com, Brian Starkey , John Stultz , =?UTF-8?Q?Christian_K=C3=B6nig?= , Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , James Jones , Hridya Valsaraju , Sandeep Patil , linux-media , DRI mailing list , "moderated list:DMA BUFFER SHARING FRAMEWORK" , linux-mm , LKML , kernel-team Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 2, 2021 at 5:39 PM Minchan Kim 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 > > Signed-off-by: Suren Baghdasaryan > Reviewed-by: Minchan Kim > > 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.