x/sys: unimplemented Linux syscalls

[Maxim Pugachev]

Hey golang-dev,

I'm wondering about unimplemented syscalls for Linux, especially timerfd. The only mention I found is in syscall_linux.go, and it's marked as "Unimplemented".

Is there any reason for that? Or it's just because of the low priority of the task, and no one had time to support it?

Thanks!

Best regards,

Maxim Pugachev

[minux]

On Mon, Apr 27, 2020 at 1:42 PM Maxim Pugachev <pugac...@gmail.com> wrote:
> I'm wondering about unimplemented syscalls for Linux, especially timerfd. The only mention I found is in syscall_linux.go, and it's marked as "Unimplemented".
> Is there any reason for that? Or it's just because of the low priority of the task, and no one had time to support it?

All the contents required by timefd_* syscalls are there, so you can
always use raw unix.Syscall and unix.Syscall6 to perform these
syscalls.
my guess the reason they do not have wrapper is that we already have a
portable timer facility that doesn't consume fd; besides, timerfd
usually requires integration with the runtime poller to be performant.
Besides timerfd_* syscalls, it seems other timer related syscalls
(like get/setitimer, and
timer_create/settime/gettime/getoverrun/delete) timer are also not
implemented, probably for the same reason.
But again, all necessary pieces are there so if you really want them,
can use them. (struct Itimerspec is not included, but it's trivial to
define your own.)

in the case for itimer, the other reason is probably the runtime uses
ITIMER_PROF for cpu profiling, so allowing user manipulation of
itimers might be undesirable. User programs should be free to use the
other two kinds of itimers though. it's just I don't see why use those
unportable features when we already have package time.

[Ian Lance Taylor]

That said, x/sys is all about unportable features. If someone wants
to add the timerfd system calls, I think that would be OK. I agree
that they would be hard to use in a Go program, but the same is true
of other functions already in x/sys.

Ian

[Maxim Pugachev]

We're deeply tied to epoll in my current project to implement low-level network code. And lack of timerfd is a problem because I have to invent various workarounds for this.

Anyway, thank you for your answers, now it's clear to me! I think that I'll try to submit my first patch then.

Best regards,

Maxim Pugachev

[Ian Lance Taylor]

On Tue, Apr 28, 2020 at 12:13 AM Maxim Pugachev <pugac...@gmail.com> wrote:
>
> We're deeply tied to epoll in my current project to implement low-level network code. And lack of timerfd is a problem because I have to invent various workarounds for this.

Out of curiosity, do you mean that you are calling epoll directly from
Go, rather than relying on the runtime poller? Why does that work
better for you?

Ian

[Maxim Pugachev]

On Thu, Apr 30, 2020 at 5:30 AM Ian Lance Taylor <ia...@golang.org> wrote:

On Tue, Apr 28, 2020 at 12:13 AM Maxim Pugachev <pugac...@gmail.com> wrote:
>
> We're deeply tied to epoll in my current project to implement low-level network code. And lack of timerfd is a problem because I have to invent various workarounds for this.

Out of curiosity, do you mean that you are calling epoll directly from
Go, rather than relying on the runtime poller?  Why does that work
better for you?

The project has strict performance requirements, so we really try to optimize on sub-ms scale. In the past, we used net/http, and everything was great until we got 1000 - 1200 qps per CPU core or something like that. Given that the default library creates many additional goroutines to handle requests, not counting those where ServeHTTP works, we've got tens of thousands of them in peak. And it really started to affect performance due to runtime overhead on scheduling. Moreover, I personally think that these issues also affect us, but it's a bit hard to prove:

https://github.com/golang/go/issues/18237

https://github.com/golang/go/issues/28808

Anyway, I wrote a simplified version of the http library and all related network code based on epoll. The main point is that sever and client "engines", as I called them, utilize only a few goroutines for all logic (not only for networking): now 4 for server code and 2 for client with CPU utilization < 50%. And it works well in our case and helps to achieve better performance.