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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D68BE77182 for ; Fri, 13 Dec 2024 15:22:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBC006B0089; Fri, 13 Dec 2024 10:22:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6A756B008C; Fri, 13 Dec 2024 10:22:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A325A6B0093; Fri, 13 Dec 2024 10:22:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7E0176B0089 for ; Fri, 13 Dec 2024 10:22:46 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F1B28C0F5F for ; Fri, 13 Dec 2024 15:22:45 +0000 (UTC) X-FDA: 82890301620.09.0CAD474 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf21.hostedemail.com (Postfix) with ESMTP id 4A7161C0007 for ; Fri, 13 Dec 2024 15:21:55 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kNV5IYVG; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of mripard@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mripard@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734103340; a=rsa-sha256; cv=none; b=dfTNqJ051u+mS7CZdmSX0MpCrgA8WBNsiqiMJ6ysEfV/29YxBFvhEComy5D1yPXrT/C8A6 1TFYVZm9vFpl791h+5bQTp0Rw7wGnCMiVY8KxmQMNXSZS4KD0WSGZEUgT3DcFfBhivNBXO otNmBqEnh3wbsmhW5gfIkdWj/euiF54= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kNV5IYVG; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of mripard@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mripard@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734103340; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mZZPTQJsNPsTvkisNXOUR5Df8ass8gl+2nYsiM1JXlA=; b=5Oe/SlIg9/JUi3ve1XRyRNl/hLntnTB1KVsTT2R/9O49A3LBKAeaawBM/Uj0XM5qB0oBCv UJWBed3cL/RvgQteLte9qvXvStP3JVUepjbIhSLxvySS9yItjTMQMbBM8BqDCxYxLuH+Vc NcvOioBBL+PK0dJtMrde7BpqY9vAnZY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 76810A42BFF; Fri, 13 Dec 2024 15:20:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F06DBC4CED0; Fri, 13 Dec 2024 15:22:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734103363; bh=mZZPTQJsNPsTvkisNXOUR5Df8ass8gl+2nYsiM1JXlA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kNV5IYVGSiAvg4nneLRmM8EESuL1qYoYf1gYdIYPnhhnv375Yc6Po7KvvI5wVwMCe aYoQTdWkXt3NEiY2O8EtAVhAJVg5265KWo8z/ExUjsIk2vpXUFHXLD0HBPWo/xGo85 D5iBbgU9KnnF7kj2nTGbkC7YoFuhPk9xa6M49WfnRZ9HxT/Qk4TD5Hv+hH/tcBjsCp jPrr9/+LA+m/8hz33JRd4nFcDFtOpZdQ1P/z06qNTdTakZWJRSNurkxGuLRNHYrOvV VE6KknCGSUAKWjqUn6zFpgNKC1Ll44mFfwwMgMAQ+YTaXEVhR9ymhvez31HSfOKOzG yh3d5lZUj/i3A== Date: Fri, 13 Dec 2024 16:22:40 +0100 From: Maxime Ripard To: Maarten Lankhorst Cc: Friedrich Vock , linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Tejun Heo , Zefan Li , Johannes Weiner , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, Maarten Lankhorst Subject: Re: [PATCH v2 0/7] kernel/cgroups: Add "dmem" memory accounting cgroup. Message-ID: <20241213-flying-naughty-marmot-6a82a2@houat> References: <20241204134410.1161769-1-dev@lankhorst.se> <29a71119-04de-4c76-a98a-d0fcb906390f@gmx.de> <20241213-sceptical-maize-gazelle-fadc34@houat> <789d78c1-d16a-4cb3-b4ad-ba5f0ddcacaf@lankhorst.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="by62sis77uqd7vzz" Content-Disposition: inline In-Reply-To: <789d78c1-d16a-4cb3-b4ad-ba5f0ddcacaf@lankhorst.se> X-Stat-Signature: zdzrd6rribrtbk7puqnskhcwtr4yj4kc X-Rspam-User: X-Rspamd-Queue-Id: 4A7161C0007 X-Rspamd-Server: rspam08 X-HE-Tag: 1734103315-137893 X-HE-Meta: U2FsdGVkX18suuQRwnxXl074HoTmopVBkrcslntnITZW0m4W5HyPSkP3PT2tt6glWoA346IeFoGnEixze/Q3u4ikflnX3A+IG2fBoVdiPiKnXa3rB1pl3DS9OwJwXx8PIZtpPSYGeJwflqQtQSoEWChigEf+pb2RBHeh2Itvt7S1GmUSW9T5sQ87XVikTqVlch/QSTZu6UU5nBZyzEg8Dwlgfi+8R8nVDr5iwCraoklpa/aQ4NmEx4zgnrvckPcRJYMTvahPQ08p5jR/0kxl3MEGEqcss5pPwlMdRl+2Y5fvn/XUhpU0VeIgSKCNjF60jB0xlYDqupf/MhAhGGv2EWbe9SlT7aX23FH40P04rAT4PLzx8+C4+GFaLWA/8F6z6FJ5FfG+fOa3GuiE6KCSkylulWywJnsnMwmfl5tywmcOV5Omcv7g+lg7gVYqd7I4Cuxkl4jIB11zK70lLxvrei9yk3ChYYGN5bvMrqyEUn2G51BTuZbuh20JDyvli7eQSIMcgBGX/tsX81+9403guWg+/p8DNkxNw5y5TI0TGTSnsukedGtOxwivRjetdwZ5zLeyltO9vq5LtOyaJZgZGeNV7TvfKjLKzYYKSWNKUmm1gEkJ+jVeIXpAKyDzym6s0c1u6vwUeroSU7p4701urLdkSIOiQLLcC9lviwrYUQGEsNCcdh/CAU7g3a0Yn9153ocD+gs5Bwv7y5Eua2i1ArhM/UwKlQFuEPaSYUzasGQ5PoRVKu9fPSVZHck5MM9VZatv9wL8dES2uPNLllSZkOsECZ0VEn+d56a37oe+9aOCVeZ44BzCHbJIXDEHpHM1N5fMWC2zkQGjxRXNC/YV4sDf4xYc+oyYqB6XJC47hBMvaixbObZfC6d9XWAf3cHPLhf6ALwbLXp7THW9sD/Sv7Umlu3sTubDb534nkY9Naiu91TCEJt0A3MZNjMj2JeF3e/SYhjkDOImbBGVF38 lQ9KM0Pf 6J8qjKYdONoUbaSOZ5o/KZK99/Um7ax9mqWoOEyPIFZzy0ucmzVgM2Qdxf+UTqL8WmlPB6SE1uXjoRbGbWQMLRQeiqkaSsLzUhvXpVqk9KQNDLfsEg54Cimplmp4aGGv0b02ZsGUiI5MXPFWKw7ebbTOW7x5GZ/scnOqACJN/92Gc0LHgu7CF14IO5rzCmCs6JFcMS1VkVnBTuEya+rt6fEEdFjlVuQv5rszCBBeZztaC16rnYPyNP4Pr8tX0NOIUCcV923jnV9rTuJPbfRTuW+Mf6qTIxk2A41eKENUzyZA0nTqhcQXALFwzfNR2b8rCZnEwVS353eC8IAetMsPZ1a18pmpDPc1rxdxw 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: List-Subscribe: List-Unsubscribe: --by62sis77uqd7vzz Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 0/7] kernel/cgroups: Add "dmem" memory accounting cgroup. MIME-Version: 1.0 On Fri, Dec 13, 2024 at 03:13:23PM +0100, Maarten Lankhorst wrote: > Hey, >=20 > Den 2024-12-13 kl. 14:07, skrev Maxime Ripard: > > On Sun, Dec 08, 2024 at 01:15:34PM +0100, Friedrich Vock wrote: > > > Hi, > > >=20 > > > On 04.12.24 14:44, Maarten Lankhorst wrote: > > >=20 > > > > Because it only deals with memory regions, the UAPI has been updated > > > > to use dmem.min/low/max/current, and to make the API cleaner, the > > > > names are changed too. > > > >=20 > > > > dmem.current could contain a line like: > > > > "drm/0000:03:00.0/vram0 1073741824" > > > >=20 > > > > But I think using "drm/card0/vram0" instead of PCIID would perhaps > > > > be good too. I'm open to changing it to that based on feedback. > > >=20 > > > Agree, allowing userspace to reference DRM devices via "cardN" syntax > > > sounds good. > > >=20 > > > What about other subsystems potentially using dmem cgroups? > > > I'm not familiar with the media subsystem, but I imagine we might be > > > dealing with things like USB devices there? Is something like a > > > "deviceN" possible there as well, or would device IDs look completely > > > different? > > I'd just take what makes sense for each driver. dev_name() would be a good > approximation. Yeah, dev_name() seems good enough to me too. > I agree that cardN is not stable. >=20 > > > I have some patches to enable the cgroup in GEM-based drivers, media > > ones and dma-buf heaps. The dma-buf heaps are simple enough since the > > heaps names are supposed to be stable. >=20 > I've used your patch as a base enable cgroup in drivers that use the VRAM > manager. I didn't want to enable it for all of GEM, because it would > conflict with drivers using TTM. Some more discussion is needed first. >=20 > For DMA-BUF heaps, I think it's fine and there is a lot less need of > discussion. I just felt it should be sent separately from the initial > enablement. Definitely. > > I don't think using card0 vs card1 (or v4l0 vs v4l1 for example) will > > work because I don't think we have any sort of guarantee that these > > names will always point to the same devices across reboots or updates. > >=20 > > If the module is loaded later than it used to for example, we could very > > well end up in a situation where card0 and card1 are swapped, while the > > constraints apply to the previous situation. > > I agree, just put it out there for discussion. I don't think the benefits > weigh up against the downsides :-) Oh absolutely. The way to define a stable name is going to be framework specific anyway. My point was that we wanted to have a stable name. Maxime --by62sis77uqd7vzz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCZ1xRQAAKCRAnX84Zoj2+ dnZVAYDQQEA9NR6GrqKYw1CvE58OitlLlx9hVBdBfbxT1+FUZK/xhIjhLN+KQYWn 9pAtNrABf2UM3dWX1eT1pN+ZKq5ToTS6/1SQjpboJ/ny+YN6Ir6UbyPmYugJN0AT +o+OtxQK8w== =HILO -----END PGP SIGNATURE----- --by62sis77uqd7vzz--