EPOLL for drm_syncfile (was Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6))

Daniel Vetter daniel at ffwll.ch
Tue May 25 05:55:34 UTC 2021


On Sun, May 23, 2021 at 11:34 PM Daniel Stone <daniel at fooishbar.org> wrote:
>
> Hi Christian,
>
> On Sun, 23 May 2021 at 18:16, Christian König <christian.koenig at amd.com> wrote:
> > Am 22.05.21 um 22:05 schrieb Daniel Stone:
> > > Anyway, the problem with syncobj is that the ioctl to wait for a
> > > sync_file to materialise for a given timeline point only allows us to
> > > block with a timeout; this is a non-starter, because we need something
> > > which fits into epoll. The most optimal case is returning a new
> > > eventfd or similar which signals when a given timeline point becomes
> > > available or signaled, but in extremis a syncobj FD becoming readable
> > > when any activity which would change the result of any zero-timeout
> > > wait on that syncobj is more or less workable.
> >
> > I think the tricky part is to epoll for a certain value.
> >
> > Not sure how eventfd is supposed to work, but IIRC we don't have the
> > functionality to poll for a certain value/offset etc to become available.
> >
> > We could of course create a separate fd for each requested value to poll
> > for thought, but that sounds like a bit much overhead to me.
>
> Yeah, I understand the point; something like an eventfd is exactly
> what you think, that we would have to materialise a new FD for it. On
> the other hand, as soon as the sync point becomes available, the
> winsys will want to immediately extract a sync_file from it, so I
> don't think FD amplification is a big issue. If it looks like being a
> problem in practice, we could look at providing a FD which starts off
> inert, and only later becomes a sync_file after it polls readable, but
> that sounds like something we really want to avoid if we can.

We can't change personalities of filp in the kernel because there's no
locking for that. But we can add a future fence state to sync_file for
this, and then make sure sync_file_get_fence() fails on them as long
as the fence hasn't materialized. That's required because current uapi
is that sync_file is never a future fence. Also opens the door for
that, which might be useful for all our userspace fences ideas.

Then we could support poll on that sync_file to wait for the fence to
materialize using POLLPRI. man poll suggests this isn't the dumbest
thing to go with, and grep in the kernel shows plenty of users (it's
EPOLLPRI internally).

With this we'd just need a new flag for allowing this mode in
sync_handle_to_fd_ioctl, and a fairly small amount of typing to glue
it together.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list