All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Rob Clark <robdclark@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Rob Clark <robdclark@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	timmurray@google.com
Subject: Re: [PATCH 0/3] drm: commit_work scheduling
Date: Mon, 21 Sep 2020 10:28:31 -0400	[thread overview]
Message-ID: <20200921142831.GA4268@mtj.duckdns.org> (raw)
In-Reply-To: <20200921092154.GJ438822@phenom.ffwll.local>

Hello,

On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> The part I don't like about this is that it all feels rather hacked
> together, and if we add more stuff (or there's some different thing in the
> system that also needs rt scheduling) then it doesn't compose.
> 
> So question to rt/worker folks: What's the best way to let userspace set
> the scheduling mode and priorities of things the kernel does on its
> behalf? Surely we're not the first ones where if userspace runs with some
> rt priority it'll starve out the kernel workers that it needs. Hardcoding
> something behind a subsystem ioctl (which just means every time userspace
> changes what it does, we need a new such flag or mode) can't be the right
> thing.

Maybe not first but there haven't been many. The main benefit of workqueue
is that the users get to pool the worker threads automatically. I don't
think the existing workqueue design is something suitable for actual RT use
cases. Furthermore, there are inherent conflicts between sharing resources
and RT as this this patchset is already showing w/ needing per-crtc worker
thread. Maybe we can further abstract it if there are more use cases but for
now kthread_worker based implementation sounds about right to me.

Thanks.

-- 
tejun

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Rob Clark <robdclark@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Rob Clark <robdclark@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	timmurray@google.com
Subject: Re: [PATCH 0/3] drm: commit_work scheduling
Date: Mon, 21 Sep 2020 10:28:31 -0400	[thread overview]
Message-ID: <20200921142831.GA4268@mtj.duckdns.org> (raw)
In-Reply-To: <20200921092154.GJ438822@phenom.ffwll.local>

Hello,

On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> The part I don't like about this is that it all feels rather hacked
> together, and if we add more stuff (or there's some different thing in the
> system that also needs rt scheduling) then it doesn't compose.
> 
> So question to rt/worker folks: What's the best way to let userspace set
> the scheduling mode and priorities of things the kernel does on its
> behalf? Surely we're not the first ones where if userspace runs with some
> rt priority it'll starve out the kernel workers that it needs. Hardcoding
> something behind a subsystem ioctl (which just means every time userspace
> changes what it does, we need a new such flag or mode) can't be the right
> thing.

Maybe not first but there haven't been many. The main benefit of workqueue
is that the users get to pool the worker threads automatically. I don't
think the existing workqueue design is something suitable for actual RT use
cases. Furthermore, there are inherent conflicts between sharing resources
and RT as this this patchset is already showing w/ needing per-crtc worker
thread. Maybe we can further abstract it if there are more use cases but for
now kthread_worker based implementation sounds about right to me.

Thanks.

-- 
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-09-21 14:28 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-19 19:37 [PATCH 0/3] drm: commit_work scheduling Rob Clark
2020-09-19 19:37 ` Rob Clark
2020-09-19 19:37 ` [PATCH 1/3] drm/crtc: Introduce per-crtc kworker Rob Clark
2020-09-19 19:37   ` Rob Clark
2020-09-21  9:20   ` Jani Nikula
2020-09-21  9:20     ` Jani Nikula
2020-09-19 19:37 ` [PATCH 2/3] drm/atomic: Use kthread worker for nonblocking commits Rob Clark
2020-09-19 19:37   ` Rob Clark
2020-09-20  1:58   ` Hillf Danton
2020-09-21  9:23   ` Daniel Vetter
2020-09-21  9:23     ` Daniel Vetter
2020-09-21 14:55     ` Rob Clark
2020-09-21 14:55       ` Rob Clark
2020-09-22 13:18       ` Daniel Vetter
2020-09-22 13:18         ` Daniel Vetter
2020-09-19 19:37 ` [PATCH 3/3] drm: Add a client-cap to set scheduling mode Rob Clark
2020-09-19 19:37   ` Rob Clark
2020-09-20  2:17   ` Hillf Danton
2020-09-21  9:21 ` [PATCH 0/3] drm: commit_work scheduling Daniel Vetter
2020-09-21  9:21   ` Daniel Vetter
2020-09-21 10:49   ` peterz
2020-09-21 10:49     ` peterz
2020-09-21 14:28   ` Tejun Heo [this message]
2020-09-21 14:28     ` Tejun Heo
2020-09-21 15:16   ` Rob Clark
2020-09-21 15:16     ` Rob Clark
2020-09-21 15:20     ` Rob Clark
2020-09-21 15:20       ` Rob Clark
2020-09-21 16:19     ` Rob Clark
2020-09-21 16:19       ` Rob Clark
2020-09-22  6:58     ` Daniel Vetter
2020-09-22  6:58       ` Daniel Vetter
2020-09-22 14:48       ` Rob Clark
2020-09-22 14:48         ` Rob Clark
2020-09-23 15:25         ` Daniel Vetter
2020-09-23 15:25           ` Daniel Vetter
2020-09-24  2:33           ` Rob Clark
2020-09-24  2:33             ` Rob Clark
2020-09-24  8:49             ` Daniel Vetter
2020-09-24  8:49               ` Daniel Vetter
2020-09-24 15:24               ` Rob Clark
2020-09-24 15:24                 ` Rob Clark
2020-09-24 16:15               ` Qais Yousef
2020-09-24 16:15                 ` Qais Yousef
2020-09-25  8:23                 ` Daniel Vetter
2020-09-25  8:23                   ` Daniel Vetter
2020-09-21 16:10 ` Qais Yousef
2020-09-21 16:10   ` Qais Yousef
2020-09-21 16:23   ` Rob Clark
2020-09-21 16:23     ` Rob Clark

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=20200921142831.GA4268@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=timmurray@google.com \
    /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.