From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3a6dcbf0845989d60e627ad4e5df4313@ladd.quanstro.net> References: <92606a17ce255a2e74049e4090d948b3@proxima.alt.za> <36c5eca0f06e9acbe2fac19067f457d8@ladd.quanstro.net> <20140519195016.B21E6B827@mail.bitblocks.com> <3a6dcbf0845989d60e627ad4e5df4313@ladd.quanstro.net> Date: Mon, 19 May 2014 13:54:30 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] syscall 53 Topicbox-Message-UUID: e8d06848-ead8-11e9-9d60-3106f5b1d025 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