From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750941AbcGLRw7 (ORCPT ); Tue, 12 Jul 2016 13:52:59 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35847 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750901AbcGLRw5 (ORCPT ); Tue, 12 Jul 2016 13:52:57 -0400 Date: Tue, 12 Jul 2016 13:52:52 -0400 From: Tejun Heo To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Christian =?iso-8859-1?Q?K=F6nig?= , Bhaktipriya Shridhar , Alex Deucher , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue Message-ID: <20160712175252.GN3190@htj.duckdns.org> References: <20160702110350.GA3601@Karyakshetra> <20160702134614.GB17431@htj.duckdns.org> <9e69b1fd-eb93-1fee-15af-c905ee3a202f@daenzer.net> <20160705210644.GB25394@htj.duckdns.org> <936c5bae-b8e6-bf64-8be2-d27608814fac@daenzer.net> <20160706134532.GF3262@mtj.duckdns.org> <85449fbd-45ba-7eea-8520-d0c19b8af001@daenzer.net> <577E081E.8030701@amd.com> <7f4299b1-a118-50ce-1f40-fbcfdfb19942@daenzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7f4299b1-a118-50ce-1f40-fbcfdfb19942@daenzer.net> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, Jul 08, 2016 at 02:52:30PM +0900, Michel Dänzer wrote: > On 07.07.2016 16:43, Christian König wrote: > >>> 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. > > How did you arrive at 2.16ms? > > Userspace can call the ioctl up to one full refresh cycle ahead of time, > which is ~16ms at 60 Hz. On the other hand userspace can also call the > ioctl arbitrarily close to the vertical blank period, in which case even > a delay of just 1ms (or even significantly less) may cause the flip to > be delayed by one refresh cycle. If there's too long a delay, the outcome is missing the refresh cycle, right? Hmmm... yeah, WQ_HIGHPRI probably is the right answer here. Bhaktipriya, can you please update the patch to use a dedicated workqueue with WQ_HIGHPRI? Thanks. -- tejun