From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753097AbcGHFxF (ORCPT ); Fri, 8 Jul 2016 01:53:05 -0400 Received: from darkcity.gna.ch ([195.226.6.51]:41982 "EHLO mail.gna.ch" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751427AbcGHFw5 (ORCPT ); Fri, 8 Jul 2016 01:52:57 -0400 Subject: Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue To: =?UTF-8?Q?Christian_K=c3=b6nig?= , Tejun Heo 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> Cc: Bhaktipriya Shridhar , Alex Deucher , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <7f4299b1-a118-50ce-1f40-fbcfdfb19942@daenzer.net> Date: Fri, 8 Jul 2016 14:52:30 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <577E081E.8030701@amd.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wTaESmK7BpQMDKD4HmH2NegghVsKGAtDG" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wTaESmK7BpQMDKD4HmH2NegghVsKGAtDG Content-Type: multipart/mixed; boundary="9eeBrm7Gr0VfGF3o0oxXDwJ6636dafKxd" From: =?UTF-8?Q?Michel_D=c3=a4nzer?= To: =?UTF-8?Q?Christian_K=c3=b6nig?= , Tejun Heo Cc: Bhaktipriya Shridhar , Alex Deucher , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Message-ID: <7f4299b1-a118-50ce-1f40-fbcfdfb19942@daenzer.net> Subject: Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue 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> In-Reply-To: <577E081E.8030701@amd.com> --9eeBrm7Gr0VfGF3o0oxXDwJ6636dafKxd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07.07.2016 16:43, Christian K=C3=B6nig wrote: > Am 07.07.2016 um 05:32 schrieb Michel D=C3=A4nzer: >> On 06.07.2016 22:45, Tejun Heo wrote: >>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel D=C3=A4nzer wrote: >>> >>>> Not being very familiar with the workqueue APIs, I'll describe how i= t's >>>> supposed to work from a driver POV, which will hopefully help you gu= ys >>>> 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= =2E >>>> When a radeon_flip_work_func item is queued, it should be executed A= SAP >>>> (so WQ_HIGHPRI might be appropriate?). >>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwis= e >>> 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. >=20 > Well to be precise with a typical 1920x1080@60 resolution you have abou= t > 2.16ms time under ideal conditions for the flip. >=20 > 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. --=20 Earthling Michel D=C3=A4nzer | http://www.amd= =2Ecom Libre software enthusiast | Mesa and X developer --9eeBrm7Gr0VfGF3o0oxXDwJ6636dafKxd-- --wTaESmK7BpQMDKD4HmH2NegghVsKGAtDG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAld/P58ACgkQWoGvjmrbsgBmvgCfYaPe8m6nFCKHDn/ik0xOKI7n 3A8AoLUeX+BSjRDs+Wr4/1HgwKo8nks9 =uj6N -----END PGP SIGNATURE----- --wTaESmK7BpQMDKD4HmH2NegghVsKGAtDG--