linux-kernel - Re: [PATCH] drm/radeon: Remove deprecated create_singlethread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jul 2016 09:45:32 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Michel Dänzer <michel@...nzer.net>
Cc:	Bhaktipriya Shridhar <bhaktipriya96@...il.com>,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/radeon: Remove deprecated
 create_singlethread_workqueue

Hello, Michel.

On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
> There is an ordering requirement between the two queues, but it's
> enforced by the driver (by only queuing the unpin work once a flip has
> completed, which only happens after the corresponding flip work has run).

Oh I see.

> 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?  Also,
what kind of delays matter here?  Is it millisec range or micro?

> In contrast, the radeon_unpin_work_func items aren't particularly
> urgent, and it's okay for several of them to be queued up. So I guess it
> would actually make sense to use a different workqueue for them, maybe
> even the default one?

If the flip work doesn't require high priority kthread, both of them
can be queued to system_wq and flushed individually on shutdown.  The
default workqueue now has high enough concurrency that it isn't
necessary to worry about getting delayed by other work items.

Thanks.

-- 
tejun