All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Rob Clark <robdclark@gmail.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>,
	Daniel Vetter <daniel@ffwll.ch>,
	Rob Clark <robdclark@chromium.org>,
	open list <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling
Date: Thu, 8 Oct 2020 11:10:17 +0200	[thread overview]
Message-ID: <20201008091017.GD438822@phenom.ffwll.local> (raw)
In-Reply-To: <20201007163010.bfgst6xfvkn2lzrk@e107158-lin.cambridge.arm.com>

On Wed, Oct 07, 2020 at 05:30:10PM +0100, Qais Yousef wrote:
> On 10/07/20 08:57, Rob Clark wrote:
> > Yeah, I think we will end up making some use of uclamp.. there is
> > someone else working on that angle
> > 
> > But without it, this is a case that exposes legit prioritization
> > problems with commit_work which we should fix ;-)
> 
> I wasn't suggesting this as an alternative to fixing the other problem. But it
> seemed you had a different problem here that I thought I could help with :-)
> 
> I did give my opinion about how to handle that priority issue. If the 2 threads
> are kernel threads and by design they need relative priorities IMO the kernel
> need to be taught to set this relative priority. It seemed the vblank worker
> could run as SCHED_DEADLINE. If this works, then the priority problem for
> commit_work disappears as SCHED_DEADLINE will preempt RT. If commit_work uses
> sched_set_fifo(), its priority will be 50, hence your SF threads can no longer
> preempt it. And you can manage the SF threads to be any value you want relative
> to 50 anyway without having to manage commit_work itself.
> 
> I'm not sure if you have problems with RT tasks preempting important CFS
> tasks. My brain registered two conflicting statements.

I think the problem is there's two modes cros runs in: Normal cros mode,
which mostly works like a linux desktop. CFS commit work seems fine.

Other mode is android emulation, where we have the surface flinger thread
running at SCHED_FIFO. I think Rob's plan is to runtime switch priorities
to match each use case.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Rob Clark <robdclark@chromium.org>,
	"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Tim Murray <timmurray@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling
Date: Thu, 8 Oct 2020 11:10:17 +0200	[thread overview]
Message-ID: <20201008091017.GD438822@phenom.ffwll.local> (raw)
In-Reply-To: <20201007163010.bfgst6xfvkn2lzrk@e107158-lin.cambridge.arm.com>

On Wed, Oct 07, 2020 at 05:30:10PM +0100, Qais Yousef wrote:
> On 10/07/20 08:57, Rob Clark wrote:
> > Yeah, I think we will end up making some use of uclamp.. there is
> > someone else working on that angle
> > 
> > But without it, this is a case that exposes legit prioritization
> > problems with commit_work which we should fix ;-)
> 
> I wasn't suggesting this as an alternative to fixing the other problem. But it
> seemed you had a different problem here that I thought I could help with :-)
> 
> I did give my opinion about how to handle that priority issue. If the 2 threads
> are kernel threads and by design they need relative priorities IMO the kernel
> need to be taught to set this relative priority. It seemed the vblank worker
> could run as SCHED_DEADLINE. If this works, then the priority problem for
> commit_work disappears as SCHED_DEADLINE will preempt RT. If commit_work uses
> sched_set_fifo(), its priority will be 50, hence your SF threads can no longer
> preempt it. And you can manage the SF threads to be any value you want relative
> to 50 anyway without having to manage commit_work itself.
> 
> I'm not sure if you have problems with RT tasks preempting important CFS
> tasks. My brain registered two conflicting statements.

I think the problem is there's two modes cros runs in: Normal cros mode,
which mostly works like a linux desktop. CFS commit work seems fine.

Other mode is android emulation, where we have the surface flinger thread
running at SCHED_FIFO. I think Rob's plan is to runtime switch priorities
to match each use case.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-08  9:10 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
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 [this message]
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=20201008091017.GD438822@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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: 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.