lkml.org 
[lkml]   [2020]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 1/9] irq_work: Cleanup

* Peter Zijlstra <peterz@infradead.org> wrote:

> Get rid of the __call_single_node union and clean up the API a little
> to avoid external code relying on the structure layout as much.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> drivers/gpu/drm/i915/i915_request.c | 4 ++--
> include/linux/irq_work.h | 33 +++++++++++++++++++++------------
> include/linux/irqflags.h | 4 ++--
> kernel/bpf/stackmap.c | 2 +-
> kernel/irq_work.c | 18 +++++++++---------
> kernel/printk/printk.c | 6 ++----
> kernel/rcu/tree.c | 3 +--
> kernel/time/tick-sched.c | 6 ++----
> kernel/trace/bpf_trace.c | 2 +-
> 9 files changed, 41 insertions(+), 37 deletions(-)
>
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -196,7 +196,7 @@ __notify_execute_cb(struct i915_request
>
> llist_for_each_entry_safe(cb, cn,
> llist_del_all(&rq->execute_cb),
> - work.llnode)
> + work.node.llist)
> fn(&cb->work);
> }
>
> @@ -478,7 +478,7 @@ __await_execution(struct i915_request *r
> * callback first, then checking the ACTIVE bit, we serialise with
> * the completed/retired request.
> */
> - if (llist_add(&cb->work.llnode, &signal->execute_cb)) {
> + if (llist_add(&cb->work.node.llist, &signal->execute_cb)) {
> if (i915_request_is_active(signal) ||
> __request_in_flight(signal))
> __notify_execute_cb_imm(signal);

Hm, so I was looking at picking up some of the low risk bits (patches #1, #2, #4)
from this series for v5.9, but the above hunk depends non-trivially on the
linux-next DRM tree, in particular:

1d9221e9d395: ("drm/i915: Skip signaling a signaled request")
3255e00edb91: ("drm/i915: Remove i915_request.lock requirement for execution callbacks")
etc.

We could add it sans the i915 bits, but then we'd introduce a semantic
conflict in linux-next which isn't nice so close to the merge window.

One solution would be to delay this into the merge window to after the
DRM tree gets merged by Linus. Another would be to help out Stephen
with the linux-next merge.

What would be your preference?

Thanks,

Ingo

\
 
 \ /
  Last update: 2020-07-25 13:59    [W:0.236 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site