All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Michel Dänzer" <michel@daenzer.net>, "Tejun Heo" <tj@kernel.org>
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue
Date: Thu, 7 Jul 2016 09:43:26 +0200	[thread overview]
Message-ID: <577E081E.8030701@amd.com> (raw)
In-Reply-To: <85449fbd-45ba-7eea-8520-d0c19b8af001@daenzer.net>

Am 07.07.2016 um 05:32 schrieb Michel Dänzer:
> On 06.07.2016 22:45, Tejun Heo wrote:
>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>>
>>> Not being very familiar with the workqueue APIs, I'll describe how it's
>>> supposed to work from a driver POV, which will hopefully help you guys
>>> decide on the most appropriate alloc_workqueue parameters.
>>>
>>> There is one flip work queue for each hardware CRTC. At most one
>>> radeon_flip_work_func item can be queued for any of them at any time.
>>> When a radeon_flip_work_func item is queued, it should be executed ASAP
>>> (so WQ_HIGHPRI might be appropriate?).
>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwise
>> require a kthread w/ nice value at -20.  Would that be the case here?
>> What are the consequences of the work item getting delayed?
> A page flip may be delayed to a later display refresh cycle.
>
>
>> Also, what kind of delays matter here?  Is it millisec range or micro?
> It can be the latter in theory, but normally rather the former.

Well to be precise with a typical 1920x1080@60 resolution you have about 
2.16ms time under ideal conditions for the flip.

So using the high priority queue still sounds like a good idea to me.

Regards,
Christian.

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michel Dänzer" <michel@daenzer.net>, "Tejun Heo" <tj@kernel.org>
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue
Date: Thu, 7 Jul 2016 09:43:26 +0200	[thread overview]
Message-ID: <577E081E.8030701@amd.com> (raw)
In-Reply-To: <85449fbd-45ba-7eea-8520-d0c19b8af001@daenzer.net>

Am 07.07.2016 um 05:32 schrieb Michel Dänzer:
> On 06.07.2016 22:45, Tejun Heo wrote:
>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>>
>>> Not being very familiar with the workqueue APIs, I'll describe how it's
>>> supposed to work from a driver POV, which will hopefully help you guys
>>> decide on the most appropriate alloc_workqueue parameters.
>>>
>>> There is one flip work queue for each hardware CRTC. At most one
>>> radeon_flip_work_func item can be queued for any of them at any time.
>>> When a radeon_flip_work_func item is queued, it should be executed ASAP
>>> (so WQ_HIGHPRI might be appropriate?).
>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwise
>> require a kthread w/ nice value at -20.  Would that be the case here?
>> What are the consequences of the work item getting delayed?
> A page flip may be delayed to a later display refresh cycle.
>
>
>> Also, what kind of delays matter here?  Is it millisec range or micro?
> It can be the latter in theory, but normally rather the former.

Well to be precise with a typical 1920x1080@60 resolution you have about 
2.16ms time under ideal conditions for the flip.

So using the high priority queue still sounds like a good idea to me.

Regards,
Christian.

  reply	other threads:[~2016-07-07  7:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-02 11:03 [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue Bhaktipriya Shridhar
2016-07-02 13:46 ` Tejun Heo
2016-07-02 13:46   ` Tejun Heo
2016-07-04  3:58   ` Michel Dänzer
2016-07-04  3:58     ` Michel Dänzer
2016-07-05 21:06     ` Tejun Heo
2016-07-05 21:06       ` Tejun Heo
2016-07-06  3:12       ` Michel Dänzer
2016-07-06  3:12         ` Michel Dänzer
2016-07-06 13:45         ` Tejun Heo
2016-07-06 13:45           ` Tejun Heo
2016-07-07  3:32           ` Michel Dänzer
2016-07-07  3:32             ` Michel Dänzer
2016-07-07  7:43             ` Christian König [this message]
2016-07-07  7:43               ` Christian König
2016-07-08  5:52               ` Michel Dänzer
2016-07-08  5:52                 ` Michel Dänzer
2016-07-12 17:52                 ` Tejun Heo
2016-07-12 17:52                   ` Tejun Heo
2016-07-16 11:30                   ` [PATCH v2] " Bhaktipriya Shridhar
2016-07-18 13:21                     ` Christian König
2016-07-18 13:21                       ` Christian König
2016-07-19  0:48                     ` Tejun Heo
2016-07-19  0:48                       ` Tejun Heo
2016-07-28 16:14                       ` Alex Deucher
2016-07-28 16:14                         ` Alex Deucher
  -- strict thread matches above, loose matches on Subject: below --
2016-06-28 17:26 [PATCH] " Bhaktipriya Shridhar
2016-06-28 17:44 ` Bhaktipriya Shridhar

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=577E081E.8030701@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=bhaktipriya96@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --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.