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 3E53CD44D46 for ; Wed, 6 Nov 2024 10:31:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF2376B0088; Wed, 6 Nov 2024 05:31:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA2846B0089; Wed, 6 Nov 2024 05:31:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96A926B008A; Wed, 6 Nov 2024 05:31:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 786A66B0088 for ; Wed, 6 Nov 2024 05:31:55 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C745C120BC1 for ; Wed, 6 Nov 2024 10:31:54 +0000 (UTC) X-FDA: 82755303036.19.2B5121D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 6142F4001A for ; Wed, 6 Nov 2024 10:31:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=sRUQaZZs; spf=pass (imf01.hostedemail.com: domain of mripard@kernel.org designates 139.178.84.217 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=1730888946; 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=oHqr3gxUoIGYJ2KixhmpeKBg9wdNtYv16Buyeyh1wWw=; b=zkz4e7Shskd6umbVcPCgHNG1E/GoI6gst8Ox31lHuvuuxgmfSP7v2AkD14btlQGHygbvAH tQ/FekU3zCVtla33NHZN13gYn/fHW6/eBaD2AtRGy+sQJShSdJwpEN5R8E1Gm1vA9MHLz6 n8D5jlXhSHVIWwf982X+cuo/GdRYtIU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=sRUQaZZs; spf=pass (imf01.hostedemail.com: domain of mripard@kernel.org designates 139.178.84.217 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=1730888946; a=rsa-sha256; cv=none; b=ptWtMy/QSD3BsMahAuf6g6o9XIFu2iHT5WwjFQ4xm3/STG10wSwQ6JRR7CyWCSC+w+TlIS jK25iYo0kKvfuxu71a4buhkwJQQcLXusUCpPgZbSNjDMHDooyoxe+jWeMw+A/bBgK6l5yr nqrlDhM1r4TkxYYXx1J40wKLhkVREFU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 388E25C4636; Wed, 6 Nov 2024 10:31:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26785C4CECD; Wed, 6 Nov 2024 10:31:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730889111; bh=oHqr3gxUoIGYJ2KixhmpeKBg9wdNtYv16Buyeyh1wWw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sRUQaZZssmmBTYP8KFopE+hRjOYsrsUhcT9tahmG2sD12UrL8K+ThjXKqpMH0m9Ke kQ+fSB9UnLYsnJjW8VSmMmuEVWT6l7suwousaZH6Q1VA7D9Bxnz5cE5cimUpa05zyN /zH0YQBZDaH8/mQa/9GmhgqQbziIr/zuGwePwu+eWqeI0nusdtJmEgopYnb5ZoB/X7 hKRgY7FYk7tSHFwIqu+Fzpwy+tiZ4inBHTExIhZFT34WE7tBV+RxAo4HDymrUceEbn ixhsQpFrz12Eu5kKEXSG9TisSur4zh3XIAMb3TAWsunGv1opItQTB3GOGDqLK4bn0p 8yJuAHmK49caA== Date: Wed, 6 Nov 2024 11:31:49 +0100 From: Maxime Ripard To: Johannes Weiner Cc: Tejun Heo , Maarten Lankhorst , intel-xe@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Zefan Li , 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: <20241106-vivacious-eagle-of-gaiety-44a419@houat> References: <20241023075302.27194-1-maarten.lankhorst@linux.intel.com> <20241024-beautiful-spaniel-of-youth-f75b61@houat> <20241028-meaty-mega-nuthatch-3d74b1@houat> <20241029203834.GA636494@cmpxchg.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="bvfw2tu3syzyhtms" Content-Disposition: inline In-Reply-To: <20241029203834.GA636494@cmpxchg.org> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 6142F4001A X-Stat-Signature: axkq3hrkpxzdm53sa59ss46jcb3mb9qt X-Rspam-User: X-HE-Tag: 1730889086-462068 X-HE-Meta: U2FsdGVkX19heR7fXqB+2fs28CDtsz8TkD/kdo9+p1wp/WLrhtGGDyM+2ggZXi6rA3JIYutdECMeAFmt/iLGxN3SpsT9w7U1F48FeXfOxUfWIab8mHeUE0f8eYcw1hdRGi14VqROl6yD3pBgLauoNTHUJYwqOcP+n0DLyZux3eKM0j0H6iW6PjiDvf65d5DjLtOyQCnprHqjeLngdD6gAEuuyJzLjWpppb4HKta3j2cJyiHDqCuvdhmaw8WSk6jA4yIoFseXQfH8UIxSTJ4hklhbiamfgQg7fGkBRVU0j2YmugJ8kP8ucunc6GsNPEkbEkNgTwOwj1Gb6xzZQlc8TEGIJ2IwtcQz4TmAXw7o3NKmx3GoBUGf7mBrni4Gpe7r7Sp4jVfbbmboTLH75wfIMWUzH2Fa/uAzQbQ1VKxR/i8iXPd2nNssoeEP6iF6Bax4vqWFYLtQy7HI4QABiCNDg/D92fXp8/BMNCrZa34bhkjUPITx3Bnm3dEddtU9crAgoi+Je5eMz2U5zNh2BKfQis6jo67pyJfqDPIhs75/AXlVJNb9KLiXDosVmJfCpxw81STGaTf38UCq+HnWTeE/MuhqBQptdFyqoC0CnstwtO6GJ4FETs8/1UFI2Ku/6DE8hUh861dsBLEZCtoKsQudIKMaooOPSSbEL5OvAAiuIu2kG6qGg1S/tUD0AJijds5vKBS0n81AaKaip588El1+CYqE8wZmUNsrizFgNmGVgNIWHBHd1M1i8wYT0XZWB5FnSMarV4K8q6vsMMGwmrDOAyOvxuq++jZQjBQ4Eu8sp2ro7Q9Gr4BTG6cNqfRuxLTHGW+PC9aH2thyahOrE3dZhgJRVzXyZSY1hpOK+7VXMO6mKoXQwI+cgWyGHtsamQ8DAEIyvN25zkZC4ZvlyBVvJhSdEzjzHGGDE9thPMMy2BexOIrNoRC2l9ROTikAZtEo50FfAnYJzsYLQZLnBXp JTzSXWwQ vv8t0vnLS/6RlPLf4ROg0gDhQaRBOxUaVoMRxvAM2CHsnZe9kJ8JHQZnNp7dlJi3oEiDkXLoQ7lifoHMNmVIBuiA42xIZpVqa3uL/RtFyaEBcgW+cgTevsZ1QKglHfRm/sjCCqnzb+gZEqHAcnJD+EwKLxSBeo+Vy4YEf97xP1E0PSOMNVKIqMMJYnk4BX0Mxnt0Hy+PoN6niA4DFeIjtM7IxnJqpCK9dYWeo9iK1xhX2lZjrkU+yBy7ZB3yJbhdq5cPwMAuhypHKZSRgylipvDI990fTaX/NadYkOCImUqMRs49QiJ6+MKyKIfFp//grd+0ly1TL1wSqVsVb91S78c6xbrK13g6hpkyP 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: --bvfw2tu3syzyhtms 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 On Tue, Oct 29, 2024 at 04:38:34PM -0400, Johannes Weiner wrote: > On Mon, Oct 28, 2024 at 11:05:48AM +0100, Maxime Ripard wrote: > > On Thu, Oct 24, 2024 at 07:06:36AM -1000, Tejun Heo wrote: > > > Hello, > > >=20 > > > On Thu, Oct 24, 2024 at 09:20:43AM +0200, Maxime Ripard wrote: > > > ... > > > > > Yeah, let's not use "dev" name for this. As Waiman pointed out, i= t conflicts > > > > > with the devices controller from cgroup1. While cgroup1 is mostly > > > > > deprecated, the same features are provided through BPF in systemd= using the > > > > > same terminologies, so this is going to be really confusing. > > > >=20 > > > > Yeah, I agree. We switched to dev because we want to support more t= han > > > > just DRM, but all DMA-able memory. We have patches to support for v= 4l2 > > > > and dma-buf heaps, so using the name DRM didn't feel great either. > > > >=20 > > > > Do you have a better name in mind? "device memory"? "dma memory"? > > >=20 > > > Maybe just dma (I think the term isn't used heavily anymore, so the w= ord is > > > kinda open)? But, hopefully, others have better ideas. > > >=20 > > > > > What happened with Tvrtko's weighted implementation? I've seen ma= ny proposed > > > > > patchsets in this area but as far as I could see none could estab= lish > > > > > consensus among GPU crowd and that's one of the reasons why nothi= ng ever > > > > > landed. Is the aim of this patchset establishing such consensus? > > > >=20 > > > > 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 imple= mentation. > > >=20 > > > That's great to hear. > > >=20 > > > > Tvrtko aims at a different feature set though: this one is about me= mory > > > > allocation limits, Tvrtko's about scheduling. > > > >=20 > > > > Scheduling doesn't make much sense for things outside of DRM (and e= ven > > > > for a fraction of all DRM devices), and it's pretty much orthogonal= =2E 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. > > >=20 > > > Yeah, I get that this is about memory and that is about processing ca= pacity, > > > so the plan is going for separate controllers for each? Or would it be > > > better to present both under the same controller interface? Even if t= hey're > > > going to be separate controllers, we at least want to be aligned on h= ow > > > devices and their configurations are presented in the two controllers. > >=20 > > It's still up in the air, I think. > >=20 > > My personal opinion is that there's only DRM (and accel) devices that > > really care about scheduling constraints anyway, so it wouldn't (have > > to) be as generic as this one. >=20 > If they represent different resources that aren't always controlled in > conjunction, it makes sense to me to have separate controllers as well. >=20 > Especially if a merged version would have separate control files for > each resource anyway (dev.region.*, dev.weight etc.) >=20 > > And if we would call it dma, then the naming becomes a bit weird since > > DMA doesn't have much to do with scheduling. > >=20 > > But I guess it's just another instance of the "naming is hard" problem = :) >=20 > Yes it would be good to have something catchy, easy on the eyes, and > vaguely familiar. devcomp(ute), devproc, devcpu, devcycles all kind of > suck. drm and gpu seem too specific for a set that includes npus and > potentially other accelerators in the future. >=20 > I don't think we want to go full devspace & devtime, either, though. >=20 > How about dmem for this one, and dpu for the other one. For device > memory and device processing unit, respectively. dmem sounds great to me, does everyone agree? Maxime --bvfw2tu3syzyhtms Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCZytFjwAKCRAnX84Zoj2+ dhP6AYCLAglFPvJTI7NGiWfJ2DaM+nbOstOAHbYN8sfYzbvWrwbe/HTF9LjCb4ra bdtt0isBf2uIVUakd0G5jxopBS0m3BsyUHYUKIjwYyAj9biATDBhXwkx/64FxALG qHcA0gz17g== =rI1J -----END PGP SIGNATURE----- --bvfw2tu3syzyhtms--