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.