Message-ID: <cdd5f892-49b9-1e22-4dc1-95a8a733c453@amd.com>
Date:   Tue, 21 Feb 2023 11:48:35 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.2
Content-Language: en-CA
To:     Rob Clark <robdclark@gmail.com>,
        Pekka Paalanen <ppaalanen@gmail.com>
Cc:     Rob Clark <robdclark@chromium.org>,
        Gustavo Padovan <gustavo@padovan.org>,
        Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
        =?UTF-8?Q?Christian_K=c3=b6nig?= <ckoenig.leichtzumerken@gmail.com>,
        =?UTF-8?Q?Michel_D=c3=a4nzer?= <michel@daenzer.net>,
        open list <linux-kernel@vger.kernel.org>,
        dri-devel@lists.freedesktop.org,
        =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@lists.linaro.org>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        freedreno@lists.freedesktop.org,
        Sumit Semwal <sumit.semwal@linaro.org>,
        "open list:SYNC FILE FRAMEWORK" <linux-media@vger.kernel.org>
References: <20230218211608.1630586-1-robdclark@gmail.com>
 <20230218211608.1630586-7-robdclark@gmail.com>
 <20230220105345.70e46fa5@eldfell>
 <CAF6AEGv9fLQCD65ytRTGp=EkNB1QoZYH5ArphgGQALV9J08Cmw@mail.gmail.com>
From:   Luben Tuikov <luben.tuikov@amd.com>
Subject: Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI
In-Reply-To: <CAF6AEGv9fLQCD65ytRTGp=EkNB1QoZYH5ArphgGQALV9J08Cmw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a09JSE5XRGMrUFNySDlFeHRVTkhoYVdiaUJqeGxndUpLOTU5YVM0eXM4TDlz?=
 =?utf-8?B?MEpxTlRFdndNSnJ3ZmZFM3RSWVo4WXVpMGFJcUMzOEdTMmNwZVF4U0pWa2VX?=
 =?utf-8?B?ZVdyS25vb2Q3RW14VkIweHlLVnJEWVRGV0hpcHVESWV3Wlh1ZUZ3WVZTd1JJ?=
 =?utf-8?B?RndGcGY3dmdKUG5NUDJzRmtlQmxtMGVVczUwZUQ3SVJJNmhqQWRlK3hhOERx?=
 =?utf-8?B?VnZ0dDRubGhoaDQwSXpvT3N1THlTVk1jMGhOcnpEeks5cmprdVlUYks0UE9X?=
 =?utf-8?B?bjMwQWtENFZrYlFGRnY1eHhHU05yaWNKa2NpZDQrWGU2a2w0Z0ppK3N4RWhk?=
 =?utf-8?B?QkNFWkNnSVN3K21IRE42bndpeXU2U0I5SCtLMXRmTm4wc0RreS9ZbkZxYTI3?=
 =?utf-8?B?eEw0TjRWamhsVXl0MktmTVhWbVRaN3VlM2FaRHZ3UnlWT2IzUjhFYjFSOFow?=
 =?utf-8?B?V2tyMUlMMWU4WktESlJVbGNJeVVPdHYwQW5yMUxDYjg5NGZ1S25iTGZnTzlX?=
 =?utf-8?B?MmZvMFVQY3lpamliNkMwd09WU24vSXFEOXlwdHp1OXRTWmRZUmFqR0hjNzBC?=
 =?utf-8?B?K2hBVEw0ajRveko5ckpyeS9ld1JnVlp2YUQ0R0wydzlvRVFxVTdkY1NrY2xa?=
 =?utf-8?B?RVFSQnpZVVllZmM3R3Q5MFd1QU9LSnVvZlR0aXlLaWlxN2o1NzZOUnVZMmdo?=
 =?utf-8?B?Y0lWVkM4MkhkWUk0anRETXAwNmhoYTVSM1hQa3NwQmp6TkhsdW5oc2Y4cE9s?=
 =?utf-8?B?aTRiRkVyUlRPY1VLc3VlSjFhSy9GUkx1eHM2RzUzL1JxMks2ZVZOYmpRdlE4?=
 =?utf-8?B?ODJ1VDc3enhTRy9HZnp1eGlmVlIwSHYyN1hRUnViOUh3OXJ1dGM2OXlaeXd2?=
 =?utf-8?B?eFdFSWd1aWNxS3M1Qmc5dGtKMGRJTHFxcXhGaUtRUm5POExqZFhVanZUY0hz?=
 =?utf-8?B?RnJjMlNyVVV1T0JRWW1COUpxL0ljU2ZBeWZSanBxTTBEMi95RWJEOHR0OWYx?=
 =?utf-8?B?bkdjQmhiVDhyNnRaTmx6YlYwNTY1V0JPdmRvNzRHUVRveW80Q3UzSnlLWGNu?=
 =?utf-8?B?YTVoTW9TVU0yaUtKaWFBdW1uck5zbVBJN2M5ZUtaRjdtcFNGYWN4Q0VTMCtQ?=
 =?utf-8?B?aW52ZSs3WkRuamV3UzRaNldHZyttdGNiaEZJbWVQbFByblhjWW40bFM3TE9H?=
 =?utf-8?B?Q2pmblRDeU1qblZqdVhFemdrby95T1I0TTF4YnVJUlFXSmtza0doNE9hYjdX?=
 =?utf-8?B?VW5QU09TQTlNakRqaUpVNjdZell1SU9uN1NQQ2NaZW5OTndEK01xeFlTdC9t?=
 =?utf-8?B?V2k3OU9XWjdxNlFGRERyK3pjRzhjeDNHc2ZpRzZFbm1GTVpMRXBwY2VCY3FK?=
 =?utf-8?B?NkoxMmk5aU9tVDZEcTQvR1VKM0ZGSDJsTTJQVXc3MTBFQU9qUTBObWczSHdO?=
 =?utf-8?B?Z1RQd2tSUzRsUnlaQ1NTVUQraTM1TEhDc1dtamxYY2FVekpadjJwaUZrRFJ3?=
 =?utf-8?B?WG52b0c0Nmd0aGRVUnBHTDN6U05oazIxMjd4RWo0R2l2R1U0RXNDU3hpQjdQ?=
 =?utf-8?B?dnZwVzRuR0JSZXFZLzEwUjlGK2NxTnBLc0ZaVXpKRGtPaFhqSmZtNWEwNDlM?=
 =?utf-8?B?dms5dGtmOWpFeGRwWjZJVHBHdTZFRFM3VVFyeGsxSkh1QVFZZTI3THphMDZO?=
 =?utf-8?B?UGtMeTVuUzlvR21NYUV2bHFOUU04WG8vb1d1bDdiZHRwTlFaK2MxQ1JaUXlF?=
 =?utf-8?B?SDI3d2ZJcmFzNTRHVmVhcDB3OUtqVVBubm5NTEt0Q0JBK3hhWTVCekhMSjRm?=
 =?utf-8?B?N1pKV0lVUjJJVy9KeC9UeXRicnFmZXhGYlZxNHFGU25xYUd0dHpBazFZNmhm?=
 =?utf-8?B?WDRSSEh1Q3ZYbDQ2TEt3NUNWS2dybTljb0w0ZjhnMUsvRENMYmF2dnNXMnJy?=
 =?utf-8?B?Y1ZxYXlpWUJxbTN3NS92YjdDLzBKb0w4MlI4bWJubTNaS2I3NDg1cXcxNUxF?=
 =?utf-8?B?NlhUYVBBenlPa3kyQ2dBR0VURS9TVndOTVBGaTBZS2llQnpRdmdoLy9iN3V2?=
 =?utf-8?B?NUNtWHlJbnJkTjEvTlpDM3J6WnRBTHZ6a29lZlBPMFA0aGpUdlBWTGRCN21l?=
 =?utf-8?Q?vTG0E68I6Xlabs/t1i4PUtOf3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30f2e10b-1160-409b-e4ee-08db142b7afc
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3370.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2023 16:48:38.4475
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nmR+XZqpMTaH2HfQJs0XGtHIDK2e8/0jDJNHjCwiQcYNU9EtwM44lbfglsB0pDpT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6588
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-02-20 11:14, Rob Clark wrote:
> On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>
>> On Sat, 18 Feb 2023 13:15:49 -0800
>> Rob Clark <robdclark@gmail.com> wrote:
>>
>>> From: Rob Clark <robdclark@chromium.org>
>>>
>>> Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
>>> wait (as opposed to a "housekeeping" wait to know when to cleanup after
>>> some work has completed).  Usermode components of GPU driver stacks
>>> often poll() on fence fd's to know when it is safe to do things like
>>> free or reuse a buffer, but they can also poll() on a fence fd when
>>> waiting to read back results from the GPU.  The EPOLLPRI/POLLPRI flag
>>> lets the kernel differentiate these two cases.
>>>
>>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>>
>> Hi,
>>
>> where would the UAPI documentation of this go?
>> It seems to be missing.
> 
> Good question, I am not sure.  The poll() man page has a description,
> but my usage doesn't fit that _exactly_ (but OTOH the description is a
> bit vague).
> 
>> If a Wayland compositor is polling application fences to know which
>> client buffer to use in its rendering, should the compositor poll with
>> PRI or not? If a compositor polls with PRI, then all fences from all
>> applications would always be PRI. Would that be harmful somehow or
>> would it be beneficial?
> 
> I think a compositor would rather use the deadline ioctl and then poll
> without PRI.  Otherwise you are giving an urgency signal to the fence
> signaller which might not necessarily be needed.
> 
> The places where I expect PRI to be useful is more in mesa (things
> like glFinish(), readpix, and other similar sorts of blocking APIs)
Hi,

Hmm, but then user-space could do the opposite, namely, submit work as usual--never 
using the SET_DEADLINE ioctl, and then at the end, poll using (E)POLLPRI. That seems
like a possible usage pattern, unintended--maybe, but possible. Do we want to discourage
this? Wouldn't SET_DEADLINE be enough? I mean, one can call SET_DEADLINE with the current
time, and then wouldn't that be equivalent to (E)POLLPRI?
-- 
Regards,
Luben