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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43BADC43217 for ; Mon, 28 Mar 2022 14:36:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243934AbiC1Oig (ORCPT ); Mon, 28 Mar 2022 10:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243913AbiC1Oid (ORCPT ); Mon, 28 Mar 2022 10:38:33 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CE885E157 for ; Mon, 28 Mar 2022 07:36:51 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id m30so20732293wrb.1 for ; Mon, 28 Mar 2022 07:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=v/hbcKwqx1gvBKjVXl56S5be+OnNXrcnFIQY2VQf+GQ=; b=P3s83mzPAy1oHFyyIJNDomqrIFEN+HTK2X/xxvM6jHZRRhY1ia7LMcyS1CUq2WRLIt 5SoYJ0xl/ZAWRBo9MGjmVgpPNSAyN2Cue489qnIcE9rOOsVfG8KpauNpaa5c3+CHpQSK gw9dIkAY9rZoEPI7OMXBY9dnJLfptFfKQMVcs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=v/hbcKwqx1gvBKjVXl56S5be+OnNXrcnFIQY2VQf+GQ=; b=JU/lasTGw4CDwM3aaCcdgO4DD5tbG5ekKBKcg1sUMUaMAhtAuAS7/yQSG/kVNvRiG4 Ws4jKUV6zIMNNQgvlLEuqTciysmlv486xOoS8hYdX2F/v/ekBe8mSiJxP5W3Dp9M4Tzd i65W7q2OvU6EWzXjmV0o1nl8fX/Q5NnIqDUCsBP7jO0Fu+ipsh6tRB0VR7r/Y4/Xnohy eGap8CESFRFCrVjeshXG6PAXAwvkTRSmu8pOnO5m8qeHW0NfPqhgDGBWTcqEmD4eER5h nJknFwYGF/pbySFL7L+aPgPiJiOQgo+2eeJh7yPX8jaZkTubfyEzpFDdsx1GAPDZ9JXv 0K7Q== X-Gm-Message-State: AOAM530d2CM6qdzDhavTITP8S2kazJBFv0fv4JVQDWVVkNscfsf90Lvi ggN4Ejg8e2uGUJIGVxilDE3BeQ== X-Google-Smtp-Source: ABdhPJy2uVCV4k6lowv1jCTyfpTR0BZIIfD37/lbvSmV0qb6ifIlu4g+nMA4zLZtNKGFclvcpohivw== X-Received: by 2002:a5d:6d8a:0:b0:204:909:2d9a with SMTP id l10-20020a5d6d8a000000b0020409092d9amr25002730wrs.435.1648478210133; Mon, 28 Mar 2022 07:36:50 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id n23-20020a05600c3b9700b0038b7c4c0803sm16778890wms.30.2022.03.28.07.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 07:36:49 -0700 (PDT) Date: Mon, 28 Mar 2022 16:36:47 +0200 From: Daniel Vetter To: "T.J. Mercier" Cc: David Airlie , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , John Stultz , Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , kaleshsingh@google.com, Kenny.Ho@amd.com, mkoutny@suse.com, skhan@linuxfoundation.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [RFC v4 4/8] dmabuf: heaps: export system_heap buffers with GPU cgroup charging Message-ID: Mail-Followup-To: "T.J. Mercier" , David Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , John Stultz , Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , kaleshsingh@google.com, Kenny.Ho@amd.com, mkoutny@suse.com, skhan@linuxfoundation.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20220328035951.1817417-1-tjmercier@google.com> <20220328035951.1817417-5-tjmercier@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220328035951.1817417-5-tjmercier@google.com> X-Operating-System: Linux phenom 5.10.0-8-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 28, 2022 at 03:59:43AM +0000, T.J. Mercier wrote: > From: Hridya Valsaraju > > All DMA heaps now register a new GPU cgroup device upon creation, and the > system_heap now exports buffers associated with its GPU cgroup device for > tracking purposes. > > Signed-off-by: Hridya Valsaraju > Signed-off-by: T.J. Mercier > > --- > v3 changes > Use more common dual author commit message format per John Stultz. > > v2 changes > Move dma-buf cgroup charge transfer from a dma_buf_op defined by every > heap to a single dma-buf function for all heaps per Daniel Vetter and > Christian König. Apologies for being out of the loop quite a bit. I scrolled through this all and I think it looks good to get going. The only thing I have is whether we should move the cgroup controllers out of dma-buf heaps, since that's rather android centric. E.g. - a system gpucg_device which is used by all the various single page allocators (dma-buf heap but also shmem helpers and really anything else) - same for cma, again both for dma-buf heaps and also for the gem cma helpers in drm Otherwise this will only work on non-upstream android where gpu drivers allocate everything from dma-buf heap. If you use something like the x86 android project with mesa drivers, then driver-internal buffers will be allocated through gem and not through dma-buf heaps. Or at least I think that's how it works. But also meh, we can fix this fairly easily later on by adding these standard gpucg_dev somwehere with a bit of kerneldoc. Anyway has my all my ack, but don't count this as my in-depth review :-) -Daniel > --- > drivers/dma-buf/dma-heap.c | 27 +++++++++++++++++++++++++++ > drivers/dma-buf/heaps/system_heap.c | 3 +++ > include/linux/dma-heap.h | 11 +++++++++++ > 3 files changed, 41 insertions(+) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 8f5848aa144f..885072427775 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -7,6 +7,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -31,6 +32,7 @@ > * @heap_devt heap device node > * @list list head connecting to list of heaps > * @heap_cdev heap char device > + * @gpucg_dev gpu cgroup device for memory accounting > * > * Represents a heap of memory from which buffers can be made. > */ > @@ -41,6 +43,9 @@ struct dma_heap { > dev_t heap_devt; > struct list_head list; > struct cdev heap_cdev; > +#ifdef CONFIG_CGROUP_GPU > + struct gpucg_device gpucg_dev; > +#endif > }; > > static LIST_HEAD(heap_list); > @@ -216,6 +221,26 @@ const char *dma_heap_get_name(struct dma_heap *heap) > return heap->name; > } > > +#ifdef CONFIG_CGROUP_GPU > +/** > + * dma_heap_get_gpucg_dev() - get struct gpucg_device for the heap. > + * @heap: DMA-Heap to get the gpucg_device struct for. > + * > + * Returns: > + * The gpucg_device struct for the heap. NULL if the GPU cgroup controller is > + * not enabled. > + */ > +struct gpucg_device *dma_heap_get_gpucg_dev(struct dma_heap *heap) > +{ > + return &heap->gpucg_dev; > +} > +#else /* CONFIG_CGROUP_GPU */ > +struct gpucg_device *dma_heap_get_gpucg_dev(struct dma_heap *heap) > +{ > + return NULL; > +} > +#endif /* CONFIG_CGROUP_GPU */ > + > struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > { > struct dma_heap *heap, *h, *err_ret; > @@ -288,6 +313,8 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > list_add(&heap->list, &heap_list); > mutex_unlock(&heap_list_lock); > > + gpucg_register_device(dma_heap_get_gpucg_dev(heap), exp_info->name); > + > return heap; > > err2: > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > index ab7fd896d2c4..752a05c3cfe2 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -395,6 +395,9 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap, > exp_info.ops = &system_heap_buf_ops; > exp_info.size = buffer->len; > exp_info.flags = fd_flags; > +#ifdef CONFIG_CGROUP_GPU > + exp_info.gpucg_dev = dma_heap_get_gpucg_dev(heap); > +#endif > exp_info.priv = buffer; > dmabuf = dma_buf_export(&exp_info); > if (IS_ERR(dmabuf)) { > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > index 0c05561cad6e..e447a61d054e 100644 > --- a/include/linux/dma-heap.h > +++ b/include/linux/dma-heap.h > @@ -10,6 +10,7 @@ > #define _DMA_HEAPS_H > > #include > +#include > #include > > struct dma_heap; > @@ -59,6 +60,16 @@ void *dma_heap_get_drvdata(struct dma_heap *heap); > */ > const char *dma_heap_get_name(struct dma_heap *heap); > > +/** > + * dma_heap_get_gpucg_dev() - get a pointer to the struct gpucg_device for the > + * heap. > + * @heap: DMA-Heap to retrieve gpucg_device for. > + * > + * Returns: > + * The gpucg_device struct for the heap. > + */ > +struct gpucg_device *dma_heap_get_gpucg_dev(struct dma_heap *heap); > + > /** > * dma_heap_add - adds a heap to dmabuf heaps > * @exp_info: information needed to register this heap > -- > 2.35.1.1021.g381101b075-goog > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch