I wasn't aware of libeio. I will take a look into it...
Just to clarify my intent, the second patch wasn't meant for
submission. Of course, I know that this cannot be accepted. The purpose
for sharing it was to share what I was doing in terms of
experimentation with your lib.
On Thu, 2021-05-06
On Wed, May 05, 2021 at 09:54:38AM -0400, Olivier Langlois
wrote:
> I tend to disagree on the future of this new API. It seems to have a
> lot of potential.
I agree it has a lot of potential, but unless the kernel people get their
act together and fix the bugs that prevent it from actually
On Tue, 2021-05-04 at 12:57 +0200, Marc Lehmann wrote:
> Thanks for trying out the iouring backend.
>
> On Wed, Apr 28, 2021 at 11:24:49AM -0400, Olivier Langlois
> wrote:
> > I believe that in order to achieve the performance gain that io_uring
> > can deliver, you would need to service I/O
Thanks for trying out the iouring backend.
On Wed, Apr 28, 2021 at 11:24:49AM -0400, Olivier Langlois
wrote:
> I believe that in order to achieve the performance gain that io_uring
> can deliver, you would need to service I/O through io_uring as well to
> save on the associated system call cost
Here is a last quick sidenote concerning my CPU usage observation.
CPU usage reported by top is now below 5% when using io_uring backend
but it seems like the CPU is spent by something else inside the kernel
as my average load did pass from 2.5 to ~3.1...
On Wed, 2021-04-28 at 11:24 -0400,
Hi,
I just wanted to report back that my usage with libev iouring backend
appears to be working super fine.
It is a WebSocket client opening about 64 TCP connections.
The test has been performed with kernel 5.11.14.
By switching from epoll backend to io_uring one, my process CPU usage
did drop
On Sun, Mar 22, 2020 at 05:57:02PM -0400, Benjamin Mahler
wrote:
> Thanks Marc, do you have any broader comments on the implications of
> iouring for libev? It looks like iouring is finally bringing async system
> calls (not just async io) to Linux.
As far as I have been told, you will even be
Thanks Marc, do you have any broader comments on the implications of
iouring for libev? It looks like iouring is finally bringing async system
calls (not just async io) to Linux. Will libeio have an iouring backend
that doesn't use a thread pool and instead hands the io off to the kernel
with
> Currently, the io_uring interface evelopment in libev is on hold, awaiting
I might add, the iouring backend can be enabled in libev-4.33, and is
expected to work. It has not really received testing, and it doesn't seem to
have speed benefits yet.
Anybody is invited to experiment with it - just
On Wed, Mar 18, 2020 at 01:19:37PM -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!
Currently, the io_uring interface evelopment in libev is on hold, awaiting
bugfixes and new
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
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.
> >
> >
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
On 12/22/19 10:39 AM, Marc Lehmann wrote:
> (Note that I have a conversation with Jens in private, as per his request,
> but since he replied to this publicly, so do I)
>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=204081 that bug
>>> https://bugzilla.kernel.org/show_bug.cgi?id=204065 oops
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
(Note that I have a conversation with Jens in private, as per his request,
but since he replied to this publicly, so do I)
> > https://bugzilla.kernel.org/show_bug.cgi?id=204081 that bug
> > https://bugzilla.kernel.org/show_bug.cgi?id=204065 oops bug
> >
On 12/22/19 7:23 AM, Marc Lehmann wrote:
> On Sat, Dec 21, 2019 at 06:45:20PM +, Benjamin Mahler
> wrote:
>> Sounds like some of the iouring findings are surprising to Jens (the
>> author).
>
> Well, I mailed him personally (no response), opened bug reports on
> bugzilla.kernel.org (no
On Sat, Dec 21, 2019 at 06:45:20PM +, Benjamin Mahler
wrote:
> Sounds like some of the iouring findings are surprising to Jens (the
> author).
Well, I mailed him personally (no response), opened bug reports on
bugzilla.kernel.org (no response), and even found a discussion on the most
On 12/21/19 11:45 AM, Benjamin Mahler wrote:
> + Jens
>
> Sounds like some of the iouring findings are surprising to Jens (the
> author).
>
> Is there a benchmark he can run to look into this?
>
> Do you have more explanation about "silently ignore parts of the
> requested events on an
+ Jens
Sounds like some of the iouring findings are surprising to Jens (the
author).
Is there a benchmark he can run to look into this?
Do you have more explanation about "silently ignore parts of the requested
events on an undocumented subset of file description types"?
On Sat, Dec 21, 2019
20 matches
Mail list logo
