On 6/1/22 12:28 PM, Linus Torvalds wrote: > On Wed, Jun 1, 2022 at 11:21 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> Of the added opcodes in io_uring, that one I'm actually certain never >> ended up getting used. I see no reason why we can't just deprecate it >> and eventually just wire it up to io_eopnotsupp(). >> >> IOW, that won't be the one holding us back killing epoll. > > That really would be lovely. > > I think io_uring at least in theory might have the potential to _help_ > kill epoll, since I suspect a lot of epoll users might well prefer > io_uring instead. > > I say "in theory", because it does require that io_uring itself > doesn't keep any of the epoll code alive, but also because we've seen > over and over that people just don't migrate to newer interfaces > because it's just too much work and the old ones still work.. > > Of course, we haven't exactly helped things - right now the whole > EPOLL thing is "default y" and behind a EXPERT define, so people > aren't even asked if they want it. Because it used to be one of those > things everybody enabled because it was new and shiny and cool. > > And sadly, there are a few things that epoll really shines at, so I > suspect that will never really change ;( I think there are two ways that io_uring can help kill epoll: 1) As a basic replacement as an event notifier. I'm not a huge fan of these conversions in general, as they just swap one readiness notifier for another one. Hence they don't end up taking full advantage of that io_uring has to offer. But they are easy and event libraries obviously often take this approach. 2) From scratch implementations or actual adoptions in applications will switch from an epoll driven readiness model to the io_uring completion model. These are the conversion that I am the most excited about, as the end up using the (imho) better model that io_uring has to offer. But as a first step, let's just mark it deprecated with a pr_warn() for 5.20 and then plan to kill it off whenever a suitable amount of relases have passed since that addition. -- Jens Axboe
