From: peterz@infradead.org
To: Rob Clark <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org,
Rob Clark <robdclark@chromium.org>,
linux-arm-msm@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
timmurray@google.com, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 0/3] drm: commit_work scheduling
Date: Mon, 21 Sep 2020 12:49:47 +0200 [thread overview]
Message-ID: <20200921104947.GQ1362448@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200921092154.GJ438822@phenom.ffwll.local>
On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> 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.
>
> Peter, Tejun?
So regular workqueues do not support RT priorities, but you can set
their nice value somewhere in /sys.
The kthread_work stuff used in these patches result in a regular kthread
and as such the user interface for changing its scheduling class or
priority is that of any other 'random' task.
WARNING: multiple messages have this Message-ID (diff)
From: peterz@infradead.org
To: Rob Clark <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org,
Rob Clark <robdclark@chromium.org>,
linux-arm-msm@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
timmurray@google.com, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 0/3] drm: commit_work scheduling
Date: Mon, 21 Sep 2020 12:49:47 +0200 [thread overview]
Message-ID: <20200921104947.GQ1362448@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200921092154.GJ438822@phenom.ffwll.local>
On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> 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.
>
> Peter, Tejun?
So regular workqueues do not support RT priorities, but you can set
their nice value somewhere in /sys.
The kthread_work stuff used in these patches result in a regular kthread
and as such the user interface for changing its scheduling class or
priority is that of any other 'random' task.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-09-21 10:49 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 [this message]
2020-09-21 10:49 ` peterz
2020-09-21 14:28 ` Tejun Heo
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=20200921104947.GQ1362448@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=timmurray@google.com \
--cc=tj@kernel.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.