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 D55CAE77186 for ; Tue, 17 Dec 2024 07:46:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED0CF6B00C3; Tue, 17 Dec 2024 02:46:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7EC46B00C4; Tue, 17 Dec 2024 02:46:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB58A6B00C5; Tue, 17 Dec 2024 02:46:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 833806B00C3 for ; Tue, 17 Dec 2024 02:46:16 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 243D6A04E5 for ; Tue, 17 Dec 2024 07:46:16 +0000 (UTC) X-FDA: 82903667028.26.84D3F2F Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf25.hostedemail.com (Postfix) with ESMTP id C43C6A0004 for ; Tue, 17 Dec 2024 07:45:52 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FgBBwHHY; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.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=1734421546; a=rsa-sha256; cv=none; b=1SO2lzNAXs/U5VP0+sgwd+zQ8t2YRg7L9QOqdlgUxM/1MVsrGX0DxvOl6YFO7KenjQREqb KaSL4RCmc6CbAA14HL7kMi9gAro2F9zfCDyKb0fDC1yNya8HrGkgCCEJ4T6jxKc4i6ZswW PTFM6kx47cUNZHYw7HM7DQxG9VL1XOU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FgBBwHHY; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.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=1734421546; 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=+Vm+eC+xSgbsQqva2V7i7wuDgSImt8XYpxOEXdlLywg=; b=HLZmt3vNDiU8FfweQgB7MJZvBKiicdU+cqUo+d2W1qRgQnzjscKhKK0s2oPq1s+Uxm+joO jPcybTv5+NdzLtIGceqGpmqy3FX7di1MwUa46VJzxRnw7jZOoKFglzAdJYyUb4XY+w6bjk ZF+k/7yZMDJXxDu/gUwk3IR1O07w+NA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E32BDA41E12; Tue, 17 Dec 2024 07:44:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0A37C4CED3; Tue, 17 Dec 2024 07:46:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734421573; bh=+Vm+eC+xSgbsQqva2V7i7wuDgSImt8XYpxOEXdlLywg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FgBBwHHYKZI1UfSFS9QBhn7KVCPW6yXxW25zCAViHTsGX4H2PU6XBB6pcGua9ACFC lDp1RIf8KYS1ML5amD4Y3t4q5JdEG+aLKWhGuvLt7KRt3/EuY4iuQM5+aNCwiqG0W2 owCVnCyvWHwb6Y06ZOzMpZilfZH2vDPBfzPYVMJRSw/C/LykUeH6ihb4K/+Nw3LppA P+24b4InOPyMWOE7YuQop6nU29CyJo4mg5t/F1KciT10WDePp35gH4aW0vEYEM2rlx ElZkOKQhMbFAUFnm8zh9pTDiQZ1npXDIwGLROYYfTnd6aRrl9DJwzQKW24QMs0rdrr IzZgEnd1p4RYQ== Date: Tue, 17 Dec 2024 08:46:10 +0100 From: Maxime Ripard To: Maarten Lankhorst Cc: linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Tejun Heo , Zefan Li , Johannes Weiner , Andrew Morton , Friedrich Vock , 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: <20241217-meek-bullfinch-of-luck-2c3468@houat> References: <20241204134410.1161769-1-dev@lankhorst.se> <20241213-proud-kind-uakari-df3a70@houat> <80c49a80-d49c-4ca5-9568-9f7950618275@lankhorst.se> <20241213-gentle-glittering-salamander-22addf@houat> <5a50a992-9286-4179-8031-ffb514bca34f@lankhorst.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="moaynkbohx6mdcjs" Content-Disposition: inline In-Reply-To: <5a50a992-9286-4179-8031-ffb514bca34f@lankhorst.se> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C43C6A0004 X-Stat-Signature: hxmg39frfz8udmq7eii3zxqu7dawqzit X-Rspam-User: X-HE-Tag: 1734421552-909700 X-HE-Meta: U2FsdGVkX18zgP8PCN9duWt7pt9PJNcqxPcvVlXkAXwoMI6bwCzw+IOY27hy7PmN4B/xvzhPoabbhDlAFVS745t+4UxAXPhGcjt1j2HpPsF3v512duJ5xOA1JQxCXpgNXQbwfm+mGCtm0IFLheCILvcQDWnNnraelt1L171GJGGPiEU6ILJSqJ9YIqLJiJAzY3XcdAqjN97refvvdXLIyyVp7iYN2T+8ypBu/glqy5X/y3Z1m7P0THhTV0lfrwBhwVeGiLh9vituN7SlJkPIJ+AwxwAIxPSGUFYqGyRFK2+1+MiTVjkkEmLxIOVNKDmX4cGjpdSGKP2XdXxtlIZqOdOHNq777wyBasDLawgoisgC/Z7oKYUjJLks/nNkLr5rpo/H9AFi1ByQpCqrPcT6lRDaX41X0vFsoZslG6GCktl/GaiA8SMQ25grAOC2z0Dwbp37vTPdJapC6EaOPJH8yVkOFLQM9EmRLY3YfgenXanqcphbJdBuxXtMxcEqCQ63C+JyfvrYDEag5e3z+uRBCnEKW53i3+HDDQyif8z8+d1rklzQaHLiOOtS1pbFluje7YNRQKI3wOS3bRRA3k8jITAorxCXthMcpqTEnjE0XNNjsGaA83VXyCjp0n1jcKi0gu4bdWCLINAn9lIUQczALB2S6/d5z98Q5kPyojcNAOyY6E5kcmnZE8z0lr1FDJ/mh0MkYJLrEhv910czYtibB0Y8o9/i1MYEj286XVNqC1z338I0NR7mvPBSaC+Oe4JX3Z2Y38IIHt42lp7m8qwuMiwS9tnuOCcz+G8+nI8/YPR+vqabh8HYi7KUruI+ab7KZf+bVwcn5wS8QN2hJT2fBqvWd64s/dETOlOy83LA5q4LDzN/NY5byMUMnmqyHm2tm8JVwfPz6jAMRSIQu/RmDGBaS2p/PXh7r5Z8FLeCfw+T+fi53PgnX2acw+cWz14AXZevfidgKdKuMfnJbkC uqzEu5oj 8Tv/L0+J5d6tFNqnB6yd3evF4r20QvZK7HuQ9c3o0TJbY4YFauAItlXgVIRu/Yn5fAv8/Ckp2ws39CetlzLlnkPkc6nDC1hbltELO/nShCXQFtPJp7x0WlGtbyf4EhgATONFjgeBn59iDcuAqvlCXLF2EHXBxlZ9mHcr6uMq0QOcbjMulEu8nwVfYhXJQHoJfk81j44F3l5x50QYhlLoVlSCZrUmg+ypetytLd5XB8hR5V3s/DPHlUVs/o8d8jU5D8DnGv9Of9zr13DBogs3YHWky2jXDIYY1Y05q7P8yGH0fzMekpL44mOmzDqlSgdtOv8UT0oWqJWV5IvLwx/3+XwbNxO/RAzRi5RKH 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: --moaynkbohx6mdcjs 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 05:06:05PM +0100, Maarten Lankhorst wrote: > Hey, >=20 > Den 2024-12-13 kl. 16:21, skrev Maxime Ripard: > > On Fri, Dec 13, 2024 at 03:53:13PM +0100, Maarten Lankhorst wrote: > > >=20 > > >=20 > > > Den 2024-12-13 kl. 14:03, skrev Maxime Ripard: > > > > Hi, > > > >=20 > > > > Thanks for the new update! > > > >=20 > > > > On Wed, Dec 04, 2024 at 02:44:00PM +0100, Maarten Lankhorst wrote: > > > > > New update. Instead of calling it the 'dev' cgroup, it's now the > > > > > 'dmem' cgroup. > > > > >=20 > > > > > Because it only deals with memory regions, the UAPI has been upda= ted > > > > > to use dmem.min/low/max/current, and to make the API cleaner, the > > > > > names are changed too. > > > >=20 > > > > The API is much nicer, and fits much better into other frameworks t= oo. > > > >=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 perhap= s be > > > > > good too. I'm open to changing it to that based on feedback. > > > >=20 > > > > Do we have any sort of guarantee over the name card0 being stable a= cross > > > > reboots? > > > >=20 > > > > I also wonder if we should have a "total" device that limits the am= ount > > > > of memory we can allocate from any region? > > >=20 > > > I don't think it is useful. Say your app can use 1 GB of main memory = or 2 GB > > > of VRAM, it wouldn't make sense to limit the total of those. In a lot= of > > > cases there is only 1 region, so the total of that would still be the= same. > > >=20 > > > On top, we just separated the management of each region, adding a 'to= tal' > > > would require unseparating it again. :-) > >=20 > > I didn't mean the total for a device, but for the system. It would > > definitely not make sense for a VRAM, but for CMA for example, you have > > a single, limited, allocator that will be accessible from heaps, v4l2 > > and DRM devices. > >=20 > > If an application has to allocate both from v4l2 and DRM buffers, we > > should be able to limit its total usage of CMA, not just on a single > > device. > > In this case, I think it makes more sense if CMA creates a region, then u= se > that region in both v4l2 and DRM instead of a separate region for both, w= ith > CMA being responsible for lifetime. Ack, thanks for your feedback :) Maxime --moaynkbohx6mdcjs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCZ2EsQQAKCRAnX84Zoj2+ dhn2AYDyBKh4PeDUj5bFOj4p/RKKL9uN/KUtyl6G3J1+sEdZdLohr1MKIZ5CF7Tl eUwVXYwBf1HikKKaUe7ZktXkTA34hBlVGvwJz/tHr0CQiuScjRmWjVDwjbQEMBUf ubiGLbrddg== =2+Ct -----END PGP SIGNATURE----- --moaynkbohx6mdcjs--