From patchwork Fri Sep 9 11:16:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lucas Stach X-Patchwork-Id: 12971579 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ED8CC6FA82 for ; Fri, 9 Sep 2022 11:16:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 837B48D0005; Fri, 9 Sep 2022 07:16:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E5848D0002; Fri, 9 Sep 2022 07:16:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 582118D0007; Fri, 9 Sep 2022 07:16:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 30D978D0001 for ; Fri, 9 Sep 2022 07:16:47 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0B924C1352 for ; Fri, 9 Sep 2022 11:16:47 +0000 (UTC) X-FDA: 79892294454.16.0B13F91 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) by imf24.hostedemail.com (Postfix) with ESMTP id 88CA01800A8 for ; Fri, 9 Sep 2022 11:16:45 +0000 (UTC) Received: from dude02.red.stw.pengutronix.de ([2a0a:edc0:0:1101:1d::28]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1oWc03-0002dP-JI; Fri, 09 Sep 2022 13:16:43 +0200 From: Lucas Stach To: linux-mm@kvack.org, dri-devel@lists.freedesktop.org Cc: Daniel Vetter , David Airlie , Andrew Morton , Michal Hocko , =?utf-8?q?Christian_K=C3=B6nig?= , linux-fsdevel@vger.kernel.org, kernel@pengutronix.de Subject: [RFC PATCH 0/5] GEM buffer memory tracking Date: Fri, 9 Sep 2022 13:16:35 +0200 Message-Id: <20220909111640.3789791-1-l.stach@pengutronix.de> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:1101:1d::28 X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mm@kvack.org ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of l.stach@pengutronix.de designates 85.220.165.71 as permitted sender) smtp.mailfrom=l.stach@pengutronix.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662722206; a=rsa-sha256; cv=none; b=xYYua+yDEVXI6W7zxnoxNWkzECc9R9t/i8Sknd1iBY3lsvZ274DHWohmjuvnt3sFY4jR9F djM/HYDuEdeb6k3ZSabExJW8HNwdEqU4imtj7lQA7qkwSC5eiikU5iEvOsZGfltoJ15yel hfzJTs8THZVLUuze3oQFJ2SvpUdVz60= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662722206; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=9Jx4FAhBbu/Ftl3PxLe1s4RzdslElEHTySkSaNzFWvc=; b=x9Z1IenxczIzgtsoNG3LtEEviPMcQq7fyzxD77NMMfQBl9/GF34sYQC8hr6zFWxn05gyiw nKmoKcXpAPne4NsCzAmXi+58IsimZ3Ljwt+F9NxT8Slx6vW+a+rK14Vm7wd8XfugDQH9hV 3teuQEUMZchcAtAv3Cz6h9bitL6EQ8M= Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of l.stach@pengutronix.de designates 85.220.165.71 as permitted sender) smtp.mailfrom=l.stach@pengutronix.de; dmarc=none X-Stat-Signature: jsrh7eidk9ui3xxdcqfcb4tn6g1h4ohe X-Rspamd-Queue-Id: 88CA01800A8 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1662722205-24071 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: Hi MM and DRM people, during the discussions about per-file OOM badness [1] it repeatedly came up that it should be possible to simply track the DRM GEM memory usage by some new MM counters. The basic problem statement is as follows: in the DRM subsystem drivers can allocate buffer aka. GEM objects on behalf of a userspace process. In many cases those buffers behave just like anonymous memory, but they may be used only by the devices driven by the DRM drivers. As the buffers can be quite large (multi-MB is the norm, rather than the exception) userspace will not map/fault them into the process address space when it doesn't need access to the content of the buffers. Thus the memory used by those buffers is not accounted to any process and evades visibility by the usual userspace tools and the OOM handling. This series tries to remedy this situation by making such memory visible by accounting it exclusively to the process that created the GEM object. For now it only hooks up the tracking to the CMA helpers and the etnaviv drivers, which was enough for me to prove the concept and see it actually working, other drivers could follow if the proposal sounds sane. Known shortcomings of this very simplistic implementation: 1. GEM objects can be shared between processes by exporting/importing them as dma-bufs. When they are shared between multiple processes, killing the process that got the memory accounted will not actually free the memory, as the object is kept alive by the sharing process. 2. It currently only accounts the full size of them GEM object, more advanced devices/drivers may only sparsely populate the backing storage of the object as needed. This could be solved by having more granular accounting. I would like to invite everyone to poke holes into this proposal to see if this might get us on the right trajectory to finally track GEM memory usage or if it (again) falls short and doesn't satisfy the requirements we have for graphics memory tracking. Regards, Lucas [1] https://lore.kernel.org/linux-mm/20220531100007.174649-1-christian.koenig@amd.com/ Lucas Stach (5): mm: add MM_DRIVERPAGES drm/gem: track mm struct of allocating process in gem object drm/gem: add functions to account GEM object memory usage drm/cma-helper: account memory used by CMA GEM objects drm/etnaviv: account memory used by GEM buffers drivers/gpu/drm/drm_gem.c | 42 +++++++++++++++++++++++++++ drivers/gpu/drm/drm_gem_cma_helper.c | 4 +++ drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++ fs/proc/task_mmu.c | 6 ++-- include/drm/drm_gem.h | 15 ++++++++++ include/linux/mm.h | 3 +- include/linux/mm_types_task.h | 1 + kernel/fork.c | 1 + 8 files changed, 72 insertions(+), 3 deletions(-)