Re: liburing: expose syscalls?

[Andres Freund <andres@anarazel.de>]

Hi,

On 2020-02-01 20:29:39 -0700, Jens Axboe wrote:
> On 2/1/20 4:30 PM, Pavel Begunkov wrote:
> > On 02/02/2020 01:51, Jens Axboe wrote:
> >>>> So you just want to have them exposed? I'd be fine with that. I'll
> >>>> take a patch :-)
> >>>>
> >>>
> >>> Depends on how it's used, but I'd strive to inline
> >>> __sys_io_uring_enter() to remove the extra indirect call into the
> >>> shared lib. Though, not sure about packaging and all this stuff. May
> >>> be useful to do that for liburing as well.
> >>
> >> Not sure that actually matters when you're doing a syscall anyway, that
> >> should be the long pole for the operation.
> >>
> > 
> > Yeah, but they are starting to stack up (+syscall() from glibc) and can became
> > even more layered on the user side.
> 
> Not saying it's free, just that I expect the actual system call to dominate.
> But I hear what you are saying, this is exactly why the liburing hot path
> resides in static inline code, and doesn't require library calls. I did
> draw the line on anything that needs a system call, figuring that wasn't
> worth over-optimizing.

That is my intuition too, especially in my case where I'm "intending" to
block in the kernel. I just tried locally, and at least with storage (a
Samsung 970 pro NVMe, in my laptop) in the path, runtime differences are
below run to run noise, and the profile doesn't show any meaningful time
spent in the indirection.

I don't really see a reason not to move syscall.c functions into a
header however. Would allow the to remove the syscall() indirection
transparently once glibc gets around supporting the syscall too. Given
that it's essentially just kernel interface definitions, how about just
putting it into liburing/io_uring.h?

I'll open a PR.  If somebody wants to bikeshed on using a name other
than __sys_*...

Greetings,

Andres Freund