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 B3BCFE7717F for ; Tue, 17 Dec 2024 14:28:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1060D6B008A; Tue, 17 Dec 2024 09:28:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 090356B0092; Tue, 17 Dec 2024 09:28:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E71C96B009A; Tue, 17 Dec 2024 09:28:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C5F856B008A for ; Tue, 17 Dec 2024 09:28:55 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 55ED7C0560 for ; Tue, 17 Dec 2024 14:28:55 +0000 (UTC) X-FDA: 82904681916.05.B263B8A Received: from mblankhorst.nl (lankhorst.se [141.105.120.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 42A5640002 for ; Tue, 17 Dec 2024 14:28:21 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=none; spf=none (imf04.hostedemail.com: domain of dev@lankhorst.se has no SPF policy when checking 141.105.120.124) smtp.mailfrom=dev@lankhorst.se ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734445720; 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=moPmzB9x314hmMk3MfhX9fl3HhuwaTUcj0UWFZnfM6A=; b=ebXvgeKm4+/j2oR7iW1E7jicYRtq02y0rrFUBjH4pe/PRBQdoBRtsD2gGrcdAHCy9C3SRy 5ZPV9UEkVhOZ5sY+n9eaIkYNZHpbHITunIxDnubUAwUR7hvNDCRj6W3CpuLdVPfrco4D96 h+LgVLr2eJ2gBRjtnyA/ay6zM3EH7bQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=none; spf=none (imf04.hostedemail.com: domain of dev@lankhorst.se has no SPF policy when checking 141.105.120.124) smtp.mailfrom=dev@lankhorst.se ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734445720; a=rsa-sha256; cv=none; b=ULSmS1sS7tycpqJVYMJNa3SQLUhRlUW2T7daalkcALdj+64nvV4q6UqFI9RRRHGmeFYX2/ NCdbfQj8R6XqqjPi7Pqq0sBNYEtKVETYg7ZH9NNjXB0wnw33ULjo1o434FaB9hNyFW/wbe IVsT8U1g3ngRTkcI3nALTDvhK+o5VFI= Message-ID: Date: Tue, 17 Dec 2024 15:28:50 +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 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 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> <20241217-meek-bullfinch-of-luck-2c3468@houat> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <20241217-meek-bullfinch-of-luck-2c3468@houat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 42A5640002 X-Stat-Signature: ado71e3y3s1cb35nx7b77a6fawribqat X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1734445701-881597 X-HE-Meta: U2FsdGVkX18SG592SFFVPXNDsGVpTfdOXn+V4BQSszzs2xhhrIGWP+8akKnLJT/2ZDYLmijKJAQ/XVl93qTObCZB6jY+3UCUB7w70Ys8mgOyvPnS1W0rRvl3ydUM1jkTCUl3cP3Ixn1jyKuuq8g7MvF5Pxq2avZYZ9SbJuTktzUFQuqHSeotG8vE9IcZgSzR0Oqn0KUEziPoIGhlaBjXEginsry2Dr5BF1vjAofa2G4La8wGW+ZpH3kum9ByqvgyNEQwWiNnVybZwN0f44fzhXydzaI+TmtwqWPsAj1VUrM9ZJlekcHUvBRzsh2w5d0GKqFC9bPRHPuUXHQXRqzDk9Jj4icSq1DSPuHa3ZOa1NQGyS+/A7jsFLniPZGM0k48w8FM1IApt8UFX0pliR97u4WaOyOTsRjtG0ho+St9ZPn/qGfPB/Pl0IxHhii8abymFNkefFnRf5siW4+L0cu61EJh7aymlrEnwKemeCwH5p06/uZZIf/9HOLPnaO80coCO/GOjD0wtNAhtOsgzPP3/PiXxX9WhIiGwmze0Jmu0sULvA4g1xFmpcXbCDF0uhtzlhemUkjIP12BSVICSz6cEnamHkw9KWGL5FfWyYE5UFXj6I2I5ewXbGvLRUjnOHpTwCR0kGfOnkzmONYn4LziJ7IMHuVCftQb6xWyDtmOETAIhPYoLd10QmxCzBMokplmF4mIYlQKPDFdzJxEBk32IAYSwjMjCXVT0xoMCIIRYPH8yuoXCaHJ7zb3vBuWVLSXaA68rqu6PEDkreW5EI1QIChtETcSGWieXaVUaZy1u8JRHSir69IQzl3JnJsrDAdpSDJPIM4LAJ+T1QZDha96xy5mFMRGjJauoRX+s4IRPbDno+KpFYSVgZFr4gr1BAH3WKQT6PNQhVaWMCa4w3wHTmdmUTp9ZMKclbmcfl+AmBjpwU/YO5AMjPDwjFG8H7tt7CF8jBUa9dmBLN3eALD a6m6K/69 bek3oOxeoC3H3hD3SVwhqw1yIenPKUj6b0lyoRBnDa845G+9wRprL5/ZwtDoKOavd/1Lmzs1uzHrEU1H5PUr59HGAjp8T6vCHKBJN9/qadNQ2F9YyPfEEtyRm0A== 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, Now that all patches look good, what is needed to merge the series? Without patch 6/7 as it is a hack for testing. I've also posted a IGT for verifying read/write works (rule out copy/paste errors) and min, max semantics work as intended. https://lists.freedesktop.org/archives/igt-dev/2024-December/083345.html Cheers, ~Maarten Den 2024-12-17 kl. 08:46, skrev Maxime Ripard: > On Fri, Dec 13, 2024 at 05:06:05PM +0100, Maarten Lankhorst wrote: >> Hey, >> >> Den 2024-12-13 kl. 16:21, skrev Maxime Ripard: >>> On Fri, Dec 13, 2024 at 03:53:13PM +0100, Maarten Lankhorst wrote: >>>> >>>> >>>> Den 2024-12-13 kl. 14:03, skrev Maxime Ripard: >>>>> Hi,l >>>>> >>>>> Thanks for the new update! >>>>> >>>>> 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. >>>>>> >>>>>> 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. >>>>> >>>>> The API is much nicer, and fits much better into other frameworks 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. >>>>> >>>>> Do we have any sort of guarantee over the name card0 being stable across >>>>> reboots? >>>>> >>>>> I also wonder if we should have a "total" device that limits the amount >>>>> of memory we can allocate from any region? >>>> >>>> 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. >>>> >>>> On top, we just separated the management of each region, adding a 'total' >>>> would require unseparating it again. :-) >>> >>> 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. >>> >>> 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 use >> that region in both v4l2 and DRM instead of a separate region for both, with >> CMA being responsible for lifetime. > > Ack, thanks for your feedback :) > > Maxime