From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
daniel@ffwll.ch
Subject: Re: [PATCH 1/7] dma-buf: some dma_fence_chain improvements
Date: Fri, 11 Jun 2021 09:49:50 +0200 [thread overview]
Message-ID: <YMMVnlo5tX5PbcrX@phenom.ffwll.local> (raw)
In-Reply-To: <20210610091800.1833-2-christian.koenig@amd.com>
On Thu, Jun 10, 2021 at 11:17:54AM +0200, Christian König wrote:
> The callback and the irq work are never used at the same
> time. Putting them into an union saves us 24 bytes and
> makes the structure only 120 bytes in size.
Yeah pushing below 128 bytes makes sense.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/dma-buf/dma-fence-chain.c | 2 +-
> include/linux/dma-fence-chain.h | 8 +++++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
> index 7d129e68ac70..1b4cb3e5cec9 100644
> --- a/drivers/dma-buf/dma-fence-chain.c
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -137,6 +137,7 @@ static void dma_fence_chain_cb(struct dma_fence *f, struct dma_fence_cb *cb)
> struct dma_fence_chain *chain;
>
> chain = container_of(cb, typeof(*chain), cb);
> + init_irq_work(&chain->work, dma_fence_chain_irq_work);
> irq_work_queue(&chain->work);
> dma_fence_put(f);
> }
> @@ -239,7 +240,6 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
> rcu_assign_pointer(chain->prev, prev);
> chain->fence = fence;
> chain->prev_seqno = 0;
> - init_irq_work(&chain->work, dma_fence_chain_irq_work);
>
> /* Try to reuse the context of the previous chain node. */
> if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) {
> diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h
> index 10462a029da2..9d6a062be640 100644
> --- a/include/linux/dma-fence-chain.h
> +++ b/include/linux/dma-fence-chain.h
> @@ -25,12 +25,14 @@
> */
> struct dma_fence_chain {
> struct dma_fence base;
> - spinlock_t lock;
> struct dma_fence __rcu *prev;
> u64 prev_seqno;
> struct dma_fence *fence;
> - struct dma_fence_cb cb;
> - struct irq_work work;
Can you pls pull the kerneldoc inline here for these too and extend the
comments that @work is only used from the callback, at which point we
don't need @cb anymore? For union lifetime tricks we really should
document this in the datastructure docs.
With that:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I also think it'd be good to specify this clearly in the kerneldoc for
dma_fence_add_callback() with something like:
"Note that the registered @cb structure is no longer in use by the
signalling code by the time @func is called, and can therefore be used
again. This is useful when @func launches a work item because it allows us
to put both the struct dma_fence_cb and the work struct (e.g. struct
work_struct) into a union to save space."
Feel free to includ this in this patch here or do a separate one.
Cheers, Daniel
> + union {
> + struct dma_fence_cb cb;
> + struct irq_work work;
> + };
> + spinlock_t lock;
> };
>
> extern const struct dma_fence_ops dma_fence_chain_ops;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/7] dma-buf: some dma_fence_chain improvements
Date: Fri, 11 Jun 2021 09:49:50 +0200 [thread overview]
Message-ID: <YMMVnlo5tX5PbcrX@phenom.ffwll.local> (raw)
In-Reply-To: <20210610091800.1833-2-christian.koenig@amd.com>
On Thu, Jun 10, 2021 at 11:17:54AM +0200, Christian König wrote:
> The callback and the irq work are never used at the same
> time. Putting them into an union saves us 24 bytes and
> makes the structure only 120 bytes in size.
Yeah pushing below 128 bytes makes sense.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/dma-buf/dma-fence-chain.c | 2 +-
> include/linux/dma-fence-chain.h | 8 +++++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
> index 7d129e68ac70..1b4cb3e5cec9 100644
> --- a/drivers/dma-buf/dma-fence-chain.c
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -137,6 +137,7 @@ static void dma_fence_chain_cb(struct dma_fence *f, struct dma_fence_cb *cb)
> struct dma_fence_chain *chain;
>
> chain = container_of(cb, typeof(*chain), cb);
> + init_irq_work(&chain->work, dma_fence_chain_irq_work);
> irq_work_queue(&chain->work);
> dma_fence_put(f);
> }
> @@ -239,7 +240,6 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
> rcu_assign_pointer(chain->prev, prev);
> chain->fence = fence;
> chain->prev_seqno = 0;
> - init_irq_work(&chain->work, dma_fence_chain_irq_work);
>
> /* Try to reuse the context of the previous chain node. */
> if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) {
> diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h
> index 10462a029da2..9d6a062be640 100644
> --- a/include/linux/dma-fence-chain.h
> +++ b/include/linux/dma-fence-chain.h
> @@ -25,12 +25,14 @@
> */
> struct dma_fence_chain {
> struct dma_fence base;
> - spinlock_t lock;
> struct dma_fence __rcu *prev;
> u64 prev_seqno;
> struct dma_fence *fence;
> - struct dma_fence_cb cb;
> - struct irq_work work;
Can you pls pull the kerneldoc inline here for these too and extend the
comments that @work is only used from the callback, at which point we
don't need @cb anymore? For union lifetime tricks we really should
document this in the datastructure docs.
With that:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I also think it'd be good to specify this clearly in the kerneldoc for
dma_fence_add_callback() with something like:
"Note that the registered @cb structure is no longer in use by the
signalling code by the time @func is called, and can therefore be used
again. This is useful when @func launches a work item because it allows us
to put both the struct dma_fence_cb and the work struct (e.g. struct
work_struct) into a union to save space."
Feel free to includ this in this patch here or do a separate one.
Cheers, Daniel
> + union {
> + struct dma_fence_cb cb;
> + struct irq_work work;
> + };
> + spinlock_t lock;
> };
>
> extern const struct dma_fence_ops dma_fence_chain_ops;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-06-11 7:49 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 9:17 Change how amdgpu stores fences in dma_resv objects Christian König
2021-06-10 9:17 ` Christian König
2021-06-10 9:17 ` [PATCH 1/7] dma-buf: some dma_fence_chain improvements Christian König
2021-06-10 9:17 ` Christian König
2021-06-11 7:49 ` Daniel Vetter [this message]
2021-06-11 7:49 ` Daniel Vetter
2021-06-10 9:17 ` [PATCH 2/7] dma-buf: add dma_fence_chain_alloc/free Christian König
2021-06-10 9:17 ` Christian König
2021-06-11 7:54 ` Daniel Vetter
2021-06-11 7:54 ` Daniel Vetter
2021-06-11 11:48 ` Christian König
2021-06-11 11:48 ` Christian König
2021-06-11 14:40 ` Daniel Vetter
2021-06-11 14:40 ` Daniel Vetter
2021-06-10 9:17 ` [PATCH 3/7] dma-buf: add dma_fence_chain_alloc/free self tests Christian König
2021-06-10 9:17 ` Christian König
2021-06-11 7:58 ` Daniel Vetter
2021-06-11 7:58 ` Daniel Vetter
2021-06-11 10:04 ` Christian König
2021-06-11 10:04 ` Christian König
2021-06-10 9:17 ` [PATCH 4/7] dma-buf: add dma_fence_chain_garbage_collect Christian König
2021-06-10 9:17 ` Christian König
2021-06-11 8:58 ` Daniel Vetter
2021-06-11 8:58 ` Daniel Vetter
2021-06-11 10:07 ` Christian König
2021-06-11 10:07 ` Christian König
2021-06-11 15:11 ` Daniel Vetter
2021-06-11 15:11 ` Daniel Vetter
2021-06-16 17:29 ` kernel test robot
2021-06-16 17:29 ` kernel test robot
2021-06-16 17:29 ` kernel test robot
2021-06-16 18:50 ` kernel test robot
2021-06-16 18:50 ` kernel test robot
2021-06-16 18:50 ` kernel test robot
2021-06-10 9:17 ` [PATCH 5/7] drm/syncobj: drop the manual garbage collection Christian König
2021-06-10 9:17 ` Christian König
2021-06-10 9:17 ` [PATCH 6/7] drm/amdgpu: unwrap fence chains in the explicit sync fence Christian König
2021-06-10 9:17 ` Christian König
2021-06-11 9:07 ` Daniel Vetter
2021-06-11 9:07 ` Daniel Vetter
2021-06-11 10:09 ` Christian König
2021-06-11 10:09 ` Christian König
2021-06-11 15:18 ` Daniel Vetter
2021-06-11 15:18 ` Daniel Vetter
2021-06-14 7:25 ` Christian König
2021-06-14 7:25 ` Christian König
2021-06-17 16:51 ` Daniel Vetter
2021-06-17 16:51 ` Daniel Vetter
2021-06-10 9:18 ` [PATCH 7/7] drm/amdgpu: rework dma_resv handling Christian König
2021-06-10 9:18 ` Christian König
2021-06-11 9:17 ` Daniel Vetter
2021-06-11 9:17 ` Daniel Vetter
2021-06-11 10:12 ` Christian König
2021-06-11 10:12 ` Christian König
2021-06-11 15:21 ` Daniel Vetter
2021-06-11 15:21 ` Daniel Vetter
2021-06-10 16:34 ` Change how amdgpu stores fences in dma_resv objects Michel Dänzer
2021-06-10 16:34 ` Michel Dänzer
2021-06-10 16:44 ` Christian König
2021-06-10 16:44 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMMVnlo5tX5PbcrX@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.