Re: [9fans] syscall 53

[ron minnich <rminnich@gmail.com>]

I've been watching the discussion but was hesitant to jump in. But
somebody asked me to say a thing or two.

We put the nsec() system call into NxM because, any way you cut it, it
provides better accuracy than the open/read/close path, particularly
when there's lots of stuff running, and the apps we care about need
that improved precision. Yes, this is measured. Just saying 'use tsc'
ignores the lack of portability of that mechanism, as well as the
other issues that have been found over the years with time registers
(core tsc synchronization, effects from power management, interaction
with virtualization, and so on). You don't have to look very long to
see that the work the kernel does for the three-system-call version is
far higher than the simple nsec system call -- yep, looks simple in
the library, and, nope, lots more going on in the kernel, more than 3x
as much. There are a few uses that break the 'it should look like a
file' model and I think this is one of them. Getting accurate,
jitter-free time is essential to making good decisions in many cases.

Nevertheless, I had not intended to push on the system call idea very
hard. As long as people were happy, there did not seem to be much
reason. So I stopped worrying about it over a year ago.

A recent discussion on golang-dev provided the final impetus: it was
recommended that if the nsec call were available on Plan 9, the Go
ports should use it. That was enough for me to put in a request for
one more review of the patch (which patch I did not put in, BTW), and
the good folks at BL felt the idea was OK, so in it went.

So it's in. It's an architecture neutral kernel interface get time in
nanoseconds in a which-core-are-you-on independent manner. It can be
made faster: on NxM the plan was to put a very fast path in the system
call assembly and return the nsec in %rax, and do the memmove in user
mode, so as to avoid any validaddr or address alignment overhead. A
true system call allows optimizations that the open/read/close
interface can not.

I'm sorry to hear that it caused trouble. That said, the problems were
due (IMHO) to a limitation in the update mechanism, not to the
inclusion of a new system call. The limitation is rarely encountered
because the situation is rarely encountered. The right way to update
the system when the kernel adds a new system call is pretty clear:
kernel first. Updating binaries before kernels is clearly wrong and
shows something could be done better. I think it's a good time to
review how the update path works and fix it.

So, it's good for Go and anything else which wants reasonable accuracy
on time without having to muck with architecture-dependent registers.
It's trivial to add. We found it helped a lot on NxM. The quality of
the results you get are hard if not impossible to equal with the
current interface. The old path still works. I think we're all going
to be ok.

ron