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 2D76CC83F03 for ; Thu, 3 Jul 2025 20:06:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F5746B0298; Thu, 3 Jul 2025 16:06:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CCE46B0299; Thu, 3 Jul 2025 16:06:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90ADE6B029A; Thu, 3 Jul 2025 16:06:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8019E6B0298 for ; Thu, 3 Jul 2025 16:06:18 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 05C741402EB for ; Thu, 3 Jul 2025 20:06:18 +0000 (UTC) X-FDA: 83624035236.20.2BCCDFD Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) by imf26.hostedemail.com (Postfix) with ESMTP id 967D2140008 for ; Thu, 3 Jul 2025 20:06:14 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=v31CKCEF; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751573174; 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:dkim-signature; bh=98sE5XXwek1MXD7aoZozn8TLYGtPuiUoHcJivbZOev0=; b=G0JyOS+sgSSiEmgrgUKkPDGitq2mClyVi1Qk3nIoWf18kfM5JpQIw3BSn+WUOJwu+C90TP FN2zOiPquZoZL7nP1RY4+SpC7LWQcJI9w909Jz7XXC0t2E9F6zNcnwmYwa9xXUyQsZ44gs gFy1KSU0vGEXHs5MvZ0Ew4+VCYeqIDU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=v31CKCEF; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751573174; a=rsa-sha256; cv=none; b=fcYPIz851BoVL1eCNIDfT1jNTbKMzz2Z6fxcncH4T1YAar8obYIoJSZNJ8fmqQ+lF6nLId cCuU6ggP3H+xCZ0fW/VB26b0G4BCTN6Wow6kOo/UREX1LOUAbQ9LcNdoUUwXo72wSF+Hyz UUFq2kiZLWc8T7hvK7KaHDri+BVRtp4= Date: Thu, 3 Jul 2025 13:06:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1751573171; h=from:from: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=98sE5XXwek1MXD7aoZozn8TLYGtPuiUoHcJivbZOev0=; b=v31CKCEFw9QRak606ceHaDT5VDVf68+LhfFxkTxliLPhqLmxvSw0N3vkaffrOAO2MxZP22 pUNxw3hHk3TepfPXK1oh3PPokw2B94I+51VveWFh/ydiJYxJl1H7EU2rHIbMBA1NI6Dtjd FHC+7sX7YTVj4NoaCqjKMWmhsw7SNRs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Christian =?utf-8?B?S8O2bmln?= Cc: David Airlie , Dave Airlie , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Johannes Weiner , Dave Chinner , Kairui Song Subject: Re: [PATCH 17/17] amdgpu: add support for memory cgroups Message-ID: References: <20250630045005.1337339-1-airlied@gmail.com> <20250630045005.1337339-18-airlied@gmail.com> <3b5t4djauhnbvhqjwuktrcphlvahpdyi2b6j3ktoapakxcvpgz@zjpokeykiwy7> <0b887b01-6de3-4633-86f7-20f5b43eeb35@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0b887b01-6de3-4633-86f7-20f5b43eeb35@amd.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 967D2140008 X-Stat-Signature: 4ngybi4cyozkju1yarbot9gbbcx9guex X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1751573174-391400 X-HE-Meta: U2FsdGVkX18+81+Ls8v+/X0RxW9+RiT0OM8YsM9e3XsMeNjmoax5YnaPbehAN+hPCOklejEkMhhWAjK5NSRsk472jWp6u9UM1kQ5zAp5NF7jonciEFnABhF1lRkjlh/Nbo5sLHYb7rKbz+Zo/R9YkMHzvouejQoqYQoKLwvtkkVG5HXKwVrGohb011YCQ00I2gvCekWV/huj1MQXMZpKyDs6WBtNGyJ8XclRpNwwtfggagYvD93yFZXzE6ycpEwPTa2jYKD9pJkwDbzuLQNoN5vhtzlpOjXGH6mVFjK67xEGVYDALpvpvBXLZnTSy6Pa6RcaZmKP4EkYgwukJH1KN9A+uOHCtuDCYaOJeC0kQF2Q4rf8nE8WpTcB9JnfU+jrOkBoPfKvnkq7taEmsDLKNuMH2Ct9WRUoFZ4UrAX/Hq1uRzAScfYPGqFURKjfGseheKfIpNlHUZd9uNlSlyaby0ica3Q1MGWQfNbuw82WWbDO4/p1XQNPPh1hRDvQMLDtTRKPGP09iPfEE+Ju/+aveNzycDUCVNx0FDAxdmlQH98hXBWEevQkDibycoUgbwYkZQbxkqWK5cgrcEv3+xEvHvgyI9LngAUQdjcmm544SZGinhQtO/e+t1fAoYYByHEUDoqlfMX4B785FTl4L8emV/KjgTbmbtBTl9lr4pf+58KuxOGtKM1jnvSYvgXgKJ6Nha5An9wpIZxTY2/T2bvXTUkHVQNZ2GIJ/KXKs0EyLNKcKarx7NRonfkN9xUzMjmBxnLLkhtolzR48uLSsnNDxaqhwxkNpnqFOPs7De+9htx2OBqzS+S6yABhfetSaF6vslOGqNjKbj37gntKr4N1YTJUXCkb3ds7XEHdFr4xGfpVFbcuLlhYr4wobJMKnIRzh24x5/Wofjl88gfi49Guzi4Hl25O3ZBrucqstG7RpJi7VsRxs+9/QKhvw7SY5j3RbXkyFqV7i5eQQMMonNC Gl+aufK3 Wbj9V6hoEs38zpP+UEZc1Jt99XerFvRB9mL3SzoaX+znvz+vEk+nm8ti8BRkOs3dDO23xQpcD4bQ0ZMT/p3mEJe/sVo29O86275/RBHRpTZ5LVUoxIW3yEWFpN0FYv8IOIfCM1p823xjaOLfUhzMymyCAYrKDTvTXxFjZV4XkDQUx8YaWATmAj1vq6OOHMRdBprt/1wYawVN7NDGFVXEbeCB7QzKGupQnJvXAHFEPx2L6xC+LlhnTR8FMVGNFswSuetcatvzP8duC/Cc= 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: On Thu, Jul 03, 2025 at 08:15:09PM +0200, Christian König wrote: > On 03.07.25 19:58, Shakeel Butt wrote: > > On Thu, Jul 03, 2025 at 12:53:44PM +1000, David Airlie wrote: > >> On Thu, Jul 3, 2025 at 2:03 AM Shakeel Butt wrote: > >>> > >>> On Mon, Jun 30, 2025 at 02:49:36PM +1000, Dave Airlie wrote: > >>>> From: Dave Airlie > >>>> > >>>> This adds support for adding a obj cgroup to a buffer object, > >>>> and passing in the placement flags to make sure it's accounted > >>>> properly. > >>>> > >>>> Signed-off-by: Dave Airlie > >>>> --- > >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 ++ > >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 +++++++++---- > >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + > >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++ > >>>> 4 files changed, 14 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > >>>> index e5e33a68d935..d250183bab03 100644 > >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > >>>> @@ -198,6 +198,7 @@ static void amdgpu_gem_object_free(struct drm_gem_object *gobj) > >>>> struct amdgpu_bo *aobj = gem_to_amdgpu_bo(gobj); > >>>> > >>>> amdgpu_hmm_unregister(aobj); > >>>> + obj_cgroup_put(aobj->tbo.objcg); > >>>> ttm_bo_put(&aobj->tbo); > >>>> } > >>>> > >>>> @@ -225,6 +226,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size, > >>>> bp.domain = initial_domain; > >>>> bp.bo_ptr_size = sizeof(struct amdgpu_bo); > >>>> bp.xcp_id_plus1 = xcp_id_plus1; > >>>> + bp.objcg = get_obj_cgroup_from_current(); > >>> > >>> In what context this function is called? Is that the same for > >>> ttm_pool_alloc_page()? Is remote charging happening in > >>> ttm_pool_alloc_page()? > >>> > >> > >> No, this function is called from userspace ioctl paths that allocate > >> GPU objects (GEM objects). > >> > >> The objects are lazily allocated, so this might not trigger any pages > >> being bound to the object, until it is populated, either via mapping + > >> page faults or by being used in a GPU command submission, which is > >> when the ttm_pool_alloc_page happens. > >> > > > > For the mapping + page fault or GPU command submission, can there be a > > case where 'current' is not in the same cgroup as the task which has > > called amdgpu_gem_object_create() through ioctl? Can the allocation > > happen in kthread or workqueue or irq? > > Yes, in some use cases that is actually the most common way of ending up in the memory allocation. > > Background is that the first one who touches it actually does the allocation. Do you mean a task in cgroup A does amdgpu_gem_object_create() and then the actual allocation can happen in the task in cgroup B? > > BTW: It might be a good idea to not only limit the amount of memory you actually have allocated, but also how much you wanted to allocate. Do you mean accounting and limiting the reservations? Something like what hugetlb cgroup provides?