On 23/05/2026 14:12, Tvrtko Ursulin wrote:
8><
I will respin next week or so. Or if you tell me the global lock can be
easily dropped from .run_job I can drop and forget about it. Wider
context is that I am experimenting with kthread_worker conversion and
trying to polish a
somewhat-broken-but-showing-great-latency-improvements branch.
Yep, I know, your experimental branch is actually on my list of things
to look at/test ;-).
Hold off a few days at least, there is a UAF in the branch Chia-I tested
and I am in the process of reworking some details to eliminate that.
FYI the new branch is at:
https://cgit.freedesktop.org/~tursulin/drm-intel/log/?h=drm-sched-kworker-single-submit
And benchmark numbers from Chia-I are at:
https://gitlab.freedesktop.org/panfrost/linux/-/work_items/49#note_3484837
Those were collected from the old branch, but I am quite confident the
fixed version will behave the same.
In summary it is quite compelling, and details aside, I guess the
question at some point will be where do we go from here. Do we proceed
in building something on top of kthread_worker, if the problem of
spawning too many threads cannot be otherwise avoided, do we go back to
the workqueue maintainers asking to re-consider adding priority
inheritance or something, or some third option.
Regards,
Tvrtko
