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 EF2BED0BB6C for ; Thu, 24 Oct 2024 07:20:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 560476B0085; Thu, 24 Oct 2024 03:20:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 537696B0088; Thu, 24 Oct 2024 03:20:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 400596B0089; Thu, 24 Oct 2024 03:20:49 -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 20CB46B0085 for ; Thu, 24 Oct 2024 03:20:49 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EBD3C1C591C for ; Thu, 24 Oct 2024 07:20:27 +0000 (UTC) X-FDA: 82707648030.21.67D7E66 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf19.hostedemail.com (Postfix) with ESMTP id 8F8651A0021 for ; Thu, 24 Oct 2024 07:20:24 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Bzz1vsgY; spf=pass (imf19.hostedemail.com: domain of mripard@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mripard@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729754395; 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=PtQkr5YsThUxbNY7HaMwj6ks7qUcxqUTc35z1yrs03E=; b=LolxWHbcd/CkM8PMDJ9uc/XzhIFSW+871gC9Be0yzxJBzqUNClGg/Y0pOlydvVVEbFIcw0 uXPprB9/yCUODSTJyFKJ2gZA8Dx+bLLUWdyIlFdkHs9aSOy/MWqbl6gabYflnSQd5/vjx5 xXV2ffM+5WhJh6cL4qXdp3SzfEluRRM= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Bzz1vsgY; spf=pass (imf19.hostedemail.com: domain of mripard@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mripard@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729754395; a=rsa-sha256; cv=none; b=3jJnCz2auoufEM9+cZHH2GVxOu+WK3OqNMACgJLGeGx44dAIVFNtKDHE8QE9e1XOiJJCuf emSKDvXsmE1snwxCxucwKfoBegI5lXfQglk4uEl32Fft5n/pGrEejyVYSce13A8Tqowzad 01pYKhMEzjNItiQir0Tc99lEVoOCsFQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 40324A45168; Thu, 24 Oct 2024 07:20:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB0CEC4CEC7; Thu, 24 Oct 2024 07:20:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729754446; bh=LR1LZ3CSRozgUjzx0t7w7Gn9212nLYiLXlkoAsdr8HA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Bzz1vsgYeJqxYsK9+eDf7kMxZK/M4s6G+t1xvYk/JmC6Tj5g/BAduwh++eLiA7bL0 8I1E1yUKMUJ7qqWH4IVu2LGv8rcEf9Y14Ov8/1oCRuduyXOcW6BmZnpZP7hUGlMq+9 0C44DJw7jbCaGNQMAv6aewqv11xbQmBCunMTz/RYSmEj58slP0EtxdpcWl0mcqa6ra bsibUS4+6bPpVC0VPYd/iC4exPI/mE3qLOkZAzhuMqtEtQEbSoOnmV+UpOfSUcLpbZ JL/UkfFq/VGGc3y+Bbdm33XZkvzlJd3qRNuiKIMewBsC3o5iZtC0EStbdE7+LJr5ua mwRiK2bpn18Fg== Date: Thu, 24 Oct 2024 09:20:43 +0200 From: Maxime Ripard To: Tejun Heo Cc: Maarten Lankhorst , intel-xe@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Zefan Li , Johannes Weiner , Andrew Morton , Friedrich Vock , cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/7] kernel/cgroups: Add "dev" memory accounting cgroup. Message-ID: <20241024-beautiful-spaniel-of-youth-f75b61@houat> References: <20241023075302.27194-1-maarten.lankhorst@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="j6zj4jbcyydfxuo7" Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: gyouwnkp77mw93d3m48q57c64jgtmk85 X-Rspamd-Queue-Id: 8F8651A0021 X-Rspamd-Server: rspam11 X-HE-Tag: 1729754424-26628 X-HE-Meta: U2FsdGVkX18wNzMrJhJCaap/ysx0ufr6IFEuFVal7TZ7rbVc4rpHiAZpJjdF8YfNCVkM9JIBAEGkxwyOCzYpeIMumHp+qZH6LO5ReZWjsNt9BLXf0+O1/WNUJ/Ssqe4Nvmtq9M9udfglsEh3KnsXAm7zPGXZxqBOERA1E0nUKsNp1EJvHaj086VYnbSnHCD6dYrw8RgukD1X3W9Cqt+7IhWYH+trNye+qLh0+qM4SKchkHyMv7mOP6J+UvwVpUvADusZwwZt4CC/GGk+UOQGH2YKX3pHKZpMF96KVlnvLwEcgXdAZmpeWU8My7HnCgzW0VAfKcAFDmDx0Rk/Sp+mfHrOfhMp1UB0KNWOqv8VVCL1O5CfUUg9meG/9vqbrgGj9TdNp7sy8xsCzppVmxa4RGBDiyejfG+eQCjFC34eV8TBFwKv+dpcUki2q1n5ZoN+6uD+x/JEQ3PXi3C4my0UJiwdzlYyKb7dKMXduUkmEscpUXZETMi3Ud2lcZWdl/Ii5X85tEQWyz6C2fNAE0x80O6HevNSmRJtFfg+bwiKoJWDnwuWcliVFasCuoOLkN5L6TvXnCb94xXjpdX52Vvg0NWYt2LAdmNlzBTg9IYOujYXXZ6KOtjHcDsX02HsTvuKv5ypSWMbAXAs5D5VvAn5AWJbayCAKatShR6XmQQ5tiWrbql5Sj7Hx6pxyjBxOiYj/zP77Hhm/7SoBKuf/fkAiAuuP3ex/u3Rkd7Yrplklzuj+OM1fDXTq36n2dZxDyEXNycTn11Lk3EWG0Zmts+a2x5FkPoGs+651SDRJM40jthsxMM/UcgfF3riu3y4Lk8M/bQaqZBD6gUjSpl6EhkpYOdGCH7mr/ivAYlYDPS32Leu2uu+EWyt5+svBq8LxgK5bEeBDPZQRr5Vjt8O8tYVnQGkGMEWn5GlZBqvNjGBn62YEHOdaKTxI5C9+Gl64Az0SgGX9UeoOf0WTL/zr45 +MG9z8QJ MjL8Q8SwCM5UW3xgZW1pdvRSNmzaHUmP5ihCJVUHoGflQFZSt6SKS+busHTiHehrdDO3DqCvI/Jg0+MQA2al4sobOc+T/GS/SB0qEYvddSHWZqIQ+dMv6faLLLEAThby3ic6RV7cyrmlh+nHQZIk6XkwX2k7lDn/XnWYUFjCGLRP2DFfKITBuIsO0T1GgWSNE40MEhTPUre93RrmIqZ9ILBgGmkLydQ7Yrl7jRg5J5lJP6n2c8VC9hTJoroq2fZ5CQmIrhYOSnimV3HwDLsfeuG90JDOj3NLKUbJqn6cqcNLfG1ol/HaBRZHunEEO6onw7Z+vZmQwUyfuFwcqjIUfLCDJeRdU8eS3XkrXOEjmpzZ46+yg+W7Bx58VVfuNrVdVYZmbDAKkB2z683L9wq+X2j/dXxs1KPbFNFde 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: --j6zj4jbcyydfxuo7 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 0/7] kernel/cgroups: Add "dev" memory accounting cgroup. MIME-Version: 1.0 Hi Tejun, Thanks a lot for your review. On Wed, Oct 23, 2024 at 09:40:28AM -1000, Tejun Heo wrote: > On Wed, Oct 23, 2024 at 09:52:53AM +0200, Maarten Lankhorst wrote: > > New submission! > > I've added documentation for each call, and integrated the renaming from > > drm cgroup to dev cgroup, based on maxime ripard's work. > >=20 > > Maxime has been testing this with dma-buf heaps and v4l2 too, and it se= ems to work. > > In the initial submission, I've decided to only add the smallest enable= ment possible, > > to have less chance of breaking things. > >=20 > > The API has been changed slightly, from "$name region.$regionname=3D$li= mit" in a file called > > dev.min/low/max to "$subsystem/$name $regionname=3D$limit" in a file ca= lled dev.region.min/low/max. > >=20 > > This hopefully allows us to perhaps extend the API later on with the po= ssibility to > > set scheduler weights on the device, like in > >=20 > > https://blogs.igalia.com/tursulin/drm-scheduling-cgroup-controller/ > >=20 > > Maarten Lankhorst (5): > > kernel/cgroup: Add "dev" memory accounting cgroup >=20 > Yeah, let's not use "dev" name for this. As Waiman pointed out, it confli= cts > with the devices controller from cgroup1. While cgroup1 is mostly > deprecated, the same features are provided through BPF in systemd using t= he > same terminologies, so this is going to be really confusing. Yeah, I agree. We switched to dev because we want to support more than just DRM, but all DMA-able memory. We have patches to support for v4l2 and dma-buf heaps, so using the name DRM didn't feel great either. Do you have a better name in mind? "device memory"? "dma memory"? > What happened with Tvrtko's weighted implementation? I've seen many propo= sed > patchsets in this area but as far as I could see none could establish > consensus among GPU crowd and that's one of the reasons why nothing ever > landed. Is the aim of this patchset establishing such consensus? Yeah, we have a consensus by now I think. Valve, Intel, Google, and Red Hat have been involved in that series and we all agree on the implementatio= n. Tvrtko aims at a different feature set though: this one is about memory allocation limits, Tvrtko's about scheduling. Scheduling doesn't make much sense for things outside of DRM (and even for a fraction of all DRM devices), and it's pretty much orthogonal. So i guess you can expect another series from Tvrtko, but I don't think they should be considered equivalent or dependent on each other. > If reaching consensus doesn't seem feasible in a predictable timeframe, my > suggesstion is just extending the misc controller. If the only way forward > here is fragmented vendor(s)-specific implementations, let's throw them i= nto > the misc controller. I don't think we have a fragmented implementation here, at all. The last patch especially implements it for all devices implementing the GEM interface in DRM, which would be around 100 drivers from various vendors. It's marked as a discussion because we don't quite know how to plumb it in for all drivers in the current DRM framework, but it's very much what we want to achieve. Maxime --j6zj4jbcyydfxuo7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCZxn1RAAKCRAnX84Zoj2+ dhOFAYDnvKCdtdyZtwff6yW6hwWh0NyRRb2B3Gl+YlgcVCEGJ4qVIO4uviaD2Pzc m1KnTrMBewRZ74IdWG+6paWjlbKquoDIPMwSmvXh2qaS8OsgoVJqlXVFoJp6wzt/ 3ARaU1tySQ== =b4FA -----END PGP SIGNATURE----- --j6zj4jbcyydfxuo7--