Re: libev-4.31 has just been released
I second that. I'm very interested in the current libev io_uring support state. I have seen a lot of commits for io_uring in the kernel 5.5.x releases for fixing bugs.It must be much more stable than it was back in December. I have seen an article this morning touting io_uring performance in the upcoming 5.6 kernel. Apparently FB is doing very well with it... https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-IO-uring-Tests On Wed, 2020-03-18 at 13:19 -0400, Benjamin Mahler wrote: > Just to follow up on this, if there have been any findings to share > I'm sure many of us in the mailing list would be interested! > > On Sun, Dec 22, 2019 at 1:32 PM Jens Axboe wrote: > > On 12/22/19 11:29 AM, Marc Lehmann wrote: > > > > > So, after a few more mails from Jens, things do get clearer. > > > > > > > > > > He never got my mail, and was concerned that my explanation made > > him > > > > > look careless, when he obviously is the opposite and wants > > io_uring to > > > > > succeed (not his words, of course - I want it to succeed :). > > > > > > > > > > And, ahm, I guess, this is all great news - things are now a lot > > more > > > > > amiable behind the scenes, and I think io_uring, if it isn't > > there > > > > > yet, will in the not so far future, BE a drop-in replacement for > > > > > select/poll,. but some work is still needed on both sides. > > > > > > > > > > So that means that I have the biggest expectation that the > > io_uring > > > > > backend will indeed become the default backend in libev on new > > enough > > > > > kernel in one of the next releases. > > > > > > > > > > Boy, I so want the epoll backend to die :) > > > > > > > > > > I already reflected some news in CVS - it seems that io_uring > > (and > > > > > already did in some cases) take care of my concerns, or at least > > makes > > > > > them a non-issue, and I am trying to coax Jens into a clear > > statement > > > > > that _all_ fds supported by either select (or at least the subset > > > > > supported by epoll) will be supported, so it will become a full > > > > > replacement for either. just nicer, and faster. But I did get the > > > > > impression that this is indeed the goal. > > > > > > > > > > Thanks, Jens, for giving me back my excitement that I felt about > > > > > io_uring originally :) > > > > > > > > Emails crossing in flight! > > > > > > > > Thanks, I think we've got it all cleared up now, and I wish I had > > read > > > > this one beore sending the previous reply. Feel free to ignore most > > of > > > > it, as I said there, most of it is procedural and I'd love to move > > on to > > > > techical issues as well! > > > > > > > > And I do apologize if my emails came across as attacks, that was > > not my > > > > intent. It's hard when the communication has been lossy, and > > assumptions > > > > are made. > > > > > > > > I'm going to enjoy my Sunday and get back to work tomorrow :-) > > > > > > > > ___libev mailing > > listli...@lists.schmorp.de > > http://lists.schmorp.de/mailman/listinfo/libev ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: libev-4.31 has just been released
Just to follow up on this, if there have been any findings to share I'm sure many of us in the mailing list would be interested! On Sun, Dec 22, 2019 at 1:32 PM Jens Axboe wrote: > On 12/22/19 11:29 AM, Marc Lehmann wrote: > > So, after a few more mails from Jens, things do get clearer. > > > > He never got my mail, and was concerned that my explanation made him > > look careless, when he obviously is the opposite and wants io_uring to > > succeed (not his words, of course - I want it to succeed :). > > > > And, ahm, I guess, this is all great news - things are now a lot more > > amiable behind the scenes, and I think io_uring, if it isn't there > > yet, will in the not so far future, BE a drop-in replacement for > > select/poll,. but some work is still needed on both sides. > > > > So that means that I have the biggest expectation that the io_uring > > backend will indeed become the default backend in libev on new enough > > kernel in one of the next releases. > > > > Boy, I so want the epoll backend to die :) > > > > I already reflected some news in CVS - it seems that io_uring (and > > already did in some cases) take care of my concerns, or at least makes > > them a non-issue, and I am trying to coax Jens into a clear statement > > that _all_ fds supported by either select (or at least the subset > > supported by epoll) will be supported, so it will become a full > > replacement for either. just nicer, and faster. But I did get the > > impression that this is indeed the goal. > > > > Thanks, Jens, for giving me back my excitement that I felt about > > io_uring originally :) > > Emails crossing in flight! > > Thanks, I think we've got it all cleared up now, and I wish I had read > this one beore sending the previous reply. Feel free to ignore most of > it, as I said there, most of it is procedural and I'd love to move on to > techical issues as well! > > And I do apologize if my emails came across as attacks, that was not my > intent. It's hard when the communication has been lossy, and assumptions > are made. > > I'm going to enjoy my Sunday and get back to work tomorrow :-) > > -- > Jens Axboe > > > ___ > libev mailing list > libev@lists.schmorp.de > http://lists.schmorp.de/mailman/listinfo/libev > ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
libev-4.33 has just been released
I am pleased to announce libev 4.33! Distribution: http://dist.schmorp.de/libev/libev-4.33.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-4_33 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-4_33 This release is mainly a bugfix/documentation/quality improvement release. The "major" new feature is ev_io_modify, which can modify the event watch mask in I/O watchers without incurring overhead caused by normally having to check whether the fd changed (as ev_io_modify doesn't change the fd), which can be substantial with some backends (i.e. epoll). The complete Changes since 4.31 are: 4.33 Wed Mar 18 13:22:29 CET 2020 - the 4.31 timerfd code wrongly changed the priority of the signal fd watcher, which is usually harmless unless signal fds are also used (found via cpan tester service). - the documentation wrongly claimed that user may modify fd and events members in io watchers when the watcher was stopped (found by b_jonas). - new ev_io_modify mutator which changes only the events member, which can be faster. also added ev::io::set (int events) method to ev++.h. - officially allow a zero events mask for io watchers. this should work with older libev versions as well but was not officially allowed before. - do not wake up every minute when timerfd is used to detect timejumps. - do not wake up every minute when periodics are disabled and we have a monotonic clock. - support a lot more "uncommon" compile time configurations, such as ev_embed enabled but ev_timer disabled. - use a start/stop wrapper class to reduce code duplication in ev++.h and make it needlessly more c++-y. - the linux aio backend is no longer compiled in by default. - update to libecb version 0x00010008. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
