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 1DA86E7717F for ; Fri, 13 Dec 2024 14:13:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7B776B007B; Fri, 13 Dec 2024 09:13:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A03886B0083; Fri, 13 Dec 2024 09:13:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CB626B0088; Fri, 13 Dec 2024 09:13:31 -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 69F876B007B for ; Fri, 13 Dec 2024 09:13:31 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 16EA7120EF7 for ; Fri, 13 Dec 2024 14:13:31 +0000 (UTC) X-FDA: 82890127614.25.9F387D3 Received: from mblankhorst.nl (lankhorst.se [141.105.120.124]) by imf22.hostedemail.com (Postfix) with ESMTP id D32CDC001A for ; Fri, 13 Dec 2024 14:13:01 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=none (imf22.hostedemail.com: domain of dev@lankhorst.se has no SPF policy when checking 141.105.120.124) smtp.mailfrom=dev@lankhorst.se; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734099191; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MzYZ1sY5Ynvpa9uneN7Wnj0AwWuv44jshCk3WiXoXTU=; b=olSeYBHg0G7+PA+guRABbPdxviBL7HtQJWM/7L+lppOyzdVhDTfSAoW9hYsw6J0p5pZX1p tkLgfzx5hHz44FU4ZBuUXQHekglcftmvwxX9EsXjdEr/8OYkGZONPvtFy9a04AcONOmOFK yE3I/T8VTCWbCWH59ML0E6H6FsTQEjM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=none (imf22.hostedemail.com: domain of dev@lankhorst.se has no SPF policy when checking 141.105.120.124) smtp.mailfrom=dev@lankhorst.se; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734099191; a=rsa-sha256; cv=none; b=Hwxr3QMoIYOn3SB2zGU6/i2sHE8Ag9ydvtBHQbKyT9A/4Ct8UCMefvtPedzaSA3PHA5871 07UlFrmOlV+Sc7rytVWM+wuUu8+5iP79NZMw8xlu9L20IAChNDjC25QJtdgQcHxEe+TRRQ g2nY5DMAh81xuLu6VzVSLZ0CzAVuhNU= Message-ID: <789d78c1-d16a-4cb3-b4ad-ba5f0ddcacaf@lankhorst.se> Date: Fri, 13 Dec 2024 15:13:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/7] kernel/cgroups: Add "dmem" memory accounting cgroup. To: Maxime Ripard , Friedrich Vock Cc: 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 References: <20241204134410.1161769-1-dev@lankhorst.se> <29a71119-04de-4c76-a98a-d0fcb906390f@gmx.de> <20241213-sceptical-maize-gazelle-fadc34@houat> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <20241213-sceptical-maize-gazelle-fadc34@houat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Stat-Signature: ibcd3y6hd8uri4sx5fjf5terze89hkkz X-Rspamd-Queue-Id: D32CDC001A X-Rspam-User: X-HE-Tag: 1734099181-748497 X-HE-Meta: U2FsdGVkX1+gjHnXI+M5EcyKfhpzVx63jINSg8pW3h1tnQ00FdmK7yOkNaGfc7i+kU1YN0/sulv3c1cansI0oKTgTZg9WhT94Qkv5WNMKjjoUo4Ggk4a++IfKTe3krPtPD7I8x5frVSskcb1iIcE+luVflVnbtYe07C5RbWbVvgI95mVyu8xqBhErcaN8Exy7rkD9fus+UFquApIE9yXOsxOV6KcUzQz0UXXho/PoZiuFQENr+ubQxscVxTlxkXiVKzEv2b64rEh9kV3RFc9aqERnkJy630k7ppff72wtYjChGMrv6oeBIH5ic0DFwhr1uPu2MNyzhsbFsYbYrcWD/twBwrKGePH+aY8jDQzjiW8xtQ6P8REqpGPgWOWhJZaxLGTi9bLdrPPxli/IYr/iBjXT62IZvadFfkOSmwJKUk9YO0PGCdJJ++3VqfEv4Oiq8LJBhyNchG2kzWyAeM60pLrQM9BHcXWBUl0cZSr9+8UAsCl+J2a1Ezvu/3MfKmougPjPV9rR41lzYj86TxmyrsqYFPhhgh7kRArdAPzilNTFvOpo/T4eFou2hk20A1NSck+sKXT3j4kCgoEgwxgO3ZQV4j5EMovvaz61e13NLyzX3fLHzwbL1Xfw9bhv7eqpEceOhK7cVNdczDL5bVWM7Su+Ao/jxeU32K+9ApCaWTUzjn//0ABuLP3xv/KU47RKZUCjHzQKLNXwbwIwJFNr/0NTHLtvGMi2RmiInDosx/8Paa6y8Gv9NaZMToI8xwgs4O4zir5GMf1UO0GnxV9kSfQIf7aksTS3pc4JnUkFwwxRVQokPY2Vg0HoMiHILeROjDHvMu6Lmj0bFkJhEiHoB/wOZscZySOldKS81Ym+Z9PW3hhZSPE3v3m2Lef8yy01R04d+y5bi50deznC8iv0jz9/N79+dySIrlaRInb6XbQAHLZkUD2fhVZUNs9zgVhs/3/ovu0fLdVWY9pYK1 IKn4mfgW fiVJXpE22+hnJ7NmQqSQlRiqI2MNeDyLzlWID 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: Hey, Den 2024-12-13 kl. 14:07, skrev Maxime Ripard: > On Sun, Dec 08, 2024 at 01:15:34PM +0100, Friedrich Vock wrote: >> Hi, >> >> On 04.12.24 14:44, Maarten Lankhorst wrote: >> >>> 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. >>> >>> dmem.current could contain a line like: >>> "drm/0000:03:00.0/vram0 1073741824" >>> >>> 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. >> >> Agree, allowing userspace to reference DRM devices via "cardN" syntax >> sounds good. >> >> 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. I agree that cardN is not stable. > > 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. 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. 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. > 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. > > 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 :-) Cheers, ~Maarten