From: Peter Zijlstra <peterz@infradead.org> To: Rob Clark <robdclark@gmail.com>, Qais Yousef <qais.yousef@arm.com>, dri-devel <dri-devel@lists.freedesktop.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Tejun Heo <tj@kernel.org>, Tim Murray <timmurray@google.com>, Rob Clark <robdclark@chromium.org>, open list <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org> Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling Date: Tue, 6 Oct 2020 12:01:13 +0200 [thread overview] Message-ID: <20201006100113.GP2628@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <20201006090859.GW438822@phenom.ffwll.local> On Tue, Oct 06, 2020 at 11:08:59AM +0200, Daniel Vetter wrote: > vblank work needs to preempt commit work. > > Right now we don't have any driver requiring this, but if we e.g. roll out > the gamma table update for i915, then this _has_ to happen in the vblank > period. > > Whereas the commit work can happen in there, but it can also be delayed a > bit (until the vblank worker has finished) we will not miss any additional > deadline due to that. > > So that's why we have 2 levels. I'm not even sure you can model that with > SCHED_DEADLINE, since essentially we need a few usec of cpu time very > vblank (16ms normally), but thos few usec _must_ be scheduled within a > very specific time slot or we're toast. And that vblank period is only > 1-2ms usually. Depends a bit on what the hardware gets us. If for example we're provided an interrupt on vblank start, then that could wake a DEADLINE job with (given your numbers above): .sched_period = 16ms, .sched_deadline = 1-2ms, .sched_runtime = 1-2ms, The effective utilization of that task would be: 1-2/16. > deadline has the upshot that it compose much better than SCHED_FIFO: > Everyone just drops their deadline requirements onto the scheduler, > scheduler makes sure it's all obeyed (or rejects your request). > > The trouble is we'd need to know how long a commit takes, worst case, on a > given platform. And for that you need to measure stuff, and we kinda can't > spend a few minutes at boot-up going through the combinatorial maze of > atomic commits to make sure we have it all. > > So I think in practice letting userspace set the right rt priority/mode is > the only way to go here :-/ Or you can have it adjust it's expected runtime as the system runs (always keeping a little extra room over what you measure to make sure). Given you have period > deadline, you can simply start with runtime = deadline and adjust downwards during use (carefully).
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org> To: Rob Clark <robdclark@gmail.com>, Qais Yousef <qais.yousef@arm.com>, dri-devel <dri-devel@lists.freedesktop.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Tejun Heo <tj@kernel.org>, Tim Murray <timmurray@google.com>, Rob Clark <robdclark@chromium.org>, open list <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org> Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling Date: Tue, 6 Oct 2020 12:01:13 +0200 [thread overview] Message-ID: <20201006100113.GP2628@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <20201006090859.GW438822@phenom.ffwll.local> On Tue, Oct 06, 2020 at 11:08:59AM +0200, Daniel Vetter wrote: > vblank work needs to preempt commit work. > > Right now we don't have any driver requiring this, but if we e.g. roll out > the gamma table update for i915, then this _has_ to happen in the vblank > period. > > Whereas the commit work can happen in there, but it can also be delayed a > bit (until the vblank worker has finished) we will not miss any additional > deadline due to that. > > So that's why we have 2 levels. I'm not even sure you can model that with > SCHED_DEADLINE, since essentially we need a few usec of cpu time very > vblank (16ms normally), but thos few usec _must_ be scheduled within a > very specific time slot or we're toast. And that vblank period is only > 1-2ms usually. Depends a bit on what the hardware gets us. If for example we're provided an interrupt on vblank start, then that could wake a DEADLINE job with (given your numbers above): .sched_period = 16ms, .sched_deadline = 1-2ms, .sched_runtime = 1-2ms, The effective utilization of that task would be: 1-2/16. > deadline has the upshot that it compose much better than SCHED_FIFO: > Everyone just drops their deadline requirements onto the scheduler, > scheduler makes sure it's all obeyed (or rejects your request). > > The trouble is we'd need to know how long a commit takes, worst case, on a > given platform. And for that you need to measure stuff, and we kinda can't > spend a few minutes at boot-up going through the combinatorial maze of > atomic commits to make sure we have it all. > > So I think in practice letting userspace set the right rt priority/mode is > the only way to go here :-/ Or you can have it adjust it's expected runtime as the system runs (always keeping a little extra room over what you measure to make sure). Given you have period > deadline, you can simply start with runtime = deadline and adjust downwards during use (carefully). _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-10-06 10:01 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-30 21:17 [PATCH v2 0/3] drm: commit_work scheduling Rob Clark 2020-09-30 21:17 ` Rob Clark 2020-09-30 21:17 ` [PATCH v2 1/3] drm/crtc: Introduce per-crtc kworker Rob Clark 2020-09-30 21:17 ` Rob Clark 2020-09-30 21:17 ` [PATCH v2 2/3] drm/atomic: Use kthread worker for nonblocking commits Rob Clark 2020-09-30 21:17 ` Rob Clark 2020-09-30 21:17 ` [PATCH v2 3/3] drm: Expose CRTC's kworker task id Rob Clark 2020-09-30 21:17 ` Rob Clark 2020-10-01 7:25 ` [PATCH v2 0/3] drm: commit_work scheduling Daniel Vetter 2020-10-01 7:25 ` Daniel Vetter 2020-10-01 15:15 ` Rob Clark 2020-10-01 15:15 ` Rob Clark 2020-10-01 15:25 ` Daniel Vetter 2020-10-01 15:25 ` Daniel Vetter 2020-10-02 10:52 ` Ville Syrjälä 2020-10-02 10:52 ` Ville Syrjälä 2020-10-02 11:05 ` Ville Syrjälä 2020-10-02 11:05 ` Ville Syrjälä 2020-10-02 17:55 ` Rob Clark 2020-10-02 17:55 ` Rob Clark 2020-10-05 12:15 ` Ville Syrjälä 2020-10-05 12:15 ` Ville Syrjälä 2020-10-05 14:15 ` Daniel Vetter 2020-10-05 14:15 ` Daniel Vetter 2020-10-05 22:58 ` Rob Clark 2020-10-05 22:58 ` Rob Clark 2020-10-07 16:44 ` Rob Clark 2020-10-07 16:44 ` Rob Clark 2020-10-08 8:24 ` Ville Syrjälä 2020-10-08 8:24 ` Ville Syrjälä 2020-10-16 16:27 ` Rob Clark 2020-10-16 16:27 ` Rob Clark 2020-10-02 11:01 ` Qais Yousef 2020-10-02 11:01 ` Qais Yousef 2020-10-02 18:07 ` Rob Clark 2020-10-02 18:07 ` Rob Clark 2020-10-05 15:00 ` Qais Yousef 2020-10-05 15:00 ` Qais Yousef 2020-10-05 23:24 ` Rob Clark 2020-10-05 23:24 ` Rob Clark 2020-10-06 9:08 ` Daniel Vetter 2020-10-06 9:08 ` Daniel Vetter 2020-10-06 10:01 ` Peter Zijlstra [this message] 2020-10-06 10:01 ` Peter Zijlstra 2020-10-06 10:59 ` Qais Yousef 2020-10-06 10:59 ` Qais Yousef 2020-10-06 20:04 ` Rob Clark 2020-10-06 20:04 ` Rob Clark 2020-10-07 10:36 ` Qais Yousef 2020-10-07 10:36 ` Qais Yousef 2020-10-07 15:57 ` Rob Clark 2020-10-07 15:57 ` Rob Clark 2020-10-07 16:30 ` Qais Yousef 2020-10-07 16:30 ` Qais Yousef 2020-10-08 9:10 ` Daniel Vetter 2020-10-08 9:10 ` Daniel Vetter
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=20201006100113.GP2628@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=qais.yousef@arm.com \ --cc=robdclark@chromium.org \ --cc=robdclark@gmail.com \ --cc=rostedt@goodmis.org \ --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: linkBe 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.