Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
Which raises another question: are 9atom and 9front in synch with the BL distribution (itself in question) regarding syscall 53? 9atom is not. i didn't know that it was added, nor do i know why nsec was added as a syscall. i indirectly heard go needs it, but that is not really a reason i can

Re: [9fans] syscall 53

2014-05-19 Thread lucio
i indirectly heard go needs it, but that is not really a reason i can understand technically. why must it be a system call? Actually, Go raised an important alert, quite indirectly: when using high resolution timers, the issue of opening a device, reading it and converting the input value to a

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote: i indirectly heard go needs it, but that is not really a reason i can understand technically. why must it be a system call? Actually, Go raised an important alert, quite indirectly: when using high resolution timers, the issue

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
On Mon May 19 12:26:00 EDT 2014, quans...@quanstro.net wrote: On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote: i indirectly heard go needs it, but that is not really a reason i can understand technically. why must it be a system call? Actually, Go raised an important

Re: [9fans] syscall 53

2014-05-19 Thread lucio
i took a quick look at the runtime·nanotime, and it looks like it's being used for gettimeofday, which shouldn't be super performance sensitive. I'm on thin ice here, but I seem to remember that the crucial issue was the resolution (nanosecond) and the expectation that Plan 9 would have to

Re: [9fans] syscall 53

2014-05-19 Thread lucio
also, one cannot get close to 1ns precision with a system call. a system call takes a bare minimum of 400-500ns on 386/amd64. Sure, but accessing /dev/time is, if I guess right, orders of magnitude slower, specially if you have to open the device first. As far as I know, that was the only

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
On Mon May 19 13:17:59 EDT 2014, lu...@proxima.alt.za wrote: also, one cannot get close to 1ns precision with a system call. a system call takes a bare minimum of 400-500ns on 386/amd64. Sure, but accessing /dev/time is, if I guess right, orders of magnitude slower, specially if you

Re: [9fans] syscall 53

2014-05-19 Thread Charles Forsyth
On 19 May 2014 18:13, lu...@proxima.alt.za wrote: Curiously, I'm pretty certain that it was the issue of an fd that remained open (something to do with caching the /dev/time fd, if I remember right) that caused some tests to fall apart, probably because a test for leaking fds actually needed

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
On 19 May 2014 18:13, lu...@proxima.alt.za wrote: Curiously, I'm pretty certain that it was the issue of an fd that remained open (something to do with caching the /dev/time fd, if I remember right) that caused some tests to fall apart, probably because a test for leaking fds actually

[9fans] waitfree

2014-05-19 Thread erik quanstrom
i've been thinking about ainc() and for the amd64 implementation, TEXT ainc(SB), 1, $-4 /* int ainc(int*) */ MOVL$1, AX LOCK; XADDL AX, (RARG) ADDL$1, AX RET does anyone know if the architecture

Re: [9fans] syscall 53

2014-05-19 Thread Aram Hăvărneanu
There are two separate issues here. First, there's the issue of whether 9front and 9atom should incorporate the change. For purely egoistic reasons, I'd like that, regardless of the technical merits of the change. I regulary test labs software on 9front. It would be a pity if I couldn't do that

Re: [9fans] syscall 53

2014-05-19 Thread Charles Forsyth
On 19 May 2014 20:15, Aram Hăvărneanu ara...@mgk.ro wrote: Some people claimed that using it leaked file descriptors in multithreaded programs. I don't understand why this problem can't be solved by opening it close-on-exec. The optimisation was a static int file descriptor. That was

Re: [9fans] waitfree

2014-05-19 Thread Devon H. O'Dell
The LOCK prefix is effectively a tiny, tiny mutex, but for all intents and purposes, this is wait-free. The LOCK prefix forces N processors to synchronize on bus and cache operations and this is how there is a guarantee of an atomic read or an atomic write. For instructions like cmpxchg and xadd

Re: [9fans] syscall 53

2014-05-19 Thread Bakul Shah
On Mon, 19 May 2014 13:25:42 EDT erik quanstrom quans...@quanstro.net wrote: i would be very surprised if there were any gain in accuracy. the accuracy is going to be dominated by the most inaccurate term, and that's likely going to be timesync, and on the order of milliseconds. Speaking of

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
I am adding some logic to synchronize with the PPS signal from the GPS device that I hooked up to a RaspberryPi. With this change the TOD clock should be accurate to within 10 to 20 µs. So I for one welcome the new syscall! [Though its introduction could've been better managed] even a

Re: [9fans] waitfree

2014-05-19 Thread erik quanstrom
On Mon May 19 15:51:27 EDT 2014, devon.od...@gmail.com wrote: The LOCK prefix is effectively a tiny, tiny mutex, but for all intents and purposes, this is wait-free. The LOCK prefix forces N processors to synchronize on bus and cache operations and this is how there is a guarantee of an atomic

Re: [9fans] syscall 53

2014-05-19 Thread erik quanstrom
There was another complaint about /dev/bintime. Some people claimed that using it leaked file descriptors in multithreaded programs. I don't understand why this problem can't be solved by opening it close-on-exec. In fact, this problem doesn't exist in the port of Go to Plan 9 anymore

Re: [9fans] syscall 53

2014-05-19 Thread ron minnich
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

Re: [9fans] waitfree

2014-05-19 Thread Devon H. O'Dell
So you seem to be worried that N processors in a tight loop of LOCK XADD could have a single processor. This isn't a problem because locked instructions have total order. Section 8.2.3.8: The memory-ordering model ensures that all processors agree on a single execution order of all locked

Re: [9fans] syscall 53

2014-05-19 Thread Charles Forsyth
On 19 May 2014 21:54, ron minnich rminn...@gmail.com wrote: jitter-free time Jitter says something about (in)consistency of time periods or intervals. It will be a function of scheduling decisions, not the overhead of a single call. In Nix, on an AP core, sure, because there isn't any

Re: [9fans] syscall 53

2014-05-19 Thread ron minnich
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth charles.fors...@gmail.com wrote: Jitter says something about (in)consistency of time periods or intervals. It will be a function of scheduling decisions, not the overhead of a single call. In Nix, on an AP core, sure, because there isn't any

Re: [9fans] waitfree

2014-05-19 Thread erik quanstrom
On Mon May 19 17:02:57 EDT 2014, devon.od...@gmail.com wrote: So you seem to be worried that N processors in a tight loop of LOCK XADD could have a single processor. This isn't a problem because locked instructions have total order. Section 8.2.3.8: The memory-ordering model ensures that all

Re: [9fans] waitfree

2014-05-19 Thread ron minnich
On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote: the documentation appears not to cover this completely. Hmm. You put documentation and completely in the same sentence. Agents are converging on your house. Run! There's always an undocumented progress engine

Re: [9fans] waitfree

2014-05-19 Thread erik quanstrom
On Mon May 19 18:15:21 EDT 2014, rminn...@gmail.com wrote: On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote: the documentation appears not to cover this completely. Hmm. You put documentation and completely in the same sentence. Agents are converging on your

Re: [9fans] syscall 53

2014-05-19 Thread Kurt H Maier
Quoting ron minnich rminn...@gmail.com: And, again, I was not inclined to act on any of this until the discussion on the golang-dev list, which boiled down to: if you can do it with a single system call, you should with a response of we put in a patch, was not accepted yet.. I just renewed the

Re: [9fans] syscall 53

2014-05-19 Thread andrey mirtchovski
golang-dev has more clout than 9fans nowadays, at least as it pertains to plan9. On Mon, May 19, 2014 at 5:02 PM, Kurt H Maier k...@sciops.net wrote: Quoting ron minnich rminn...@gmail.com: And, again, I was not inclined to act on any of this until the discussion on the golang-dev list, which

Re: [9fans] syscall 53

2014-05-19 Thread Kurt H Maier
Quoting andrey mirtchovski mirtchov...@gmail.com: golang-dev has more clout than 9fans nowadays, at least as it pertains to plan9. That's why I'm asking. We now have three go-related new syscalls, while lots of actual hardware support gets flushed down the toilet for unspecified reasons.

Re: [9fans] syscall 53

2014-05-19 Thread andrey mirtchovski
I suggest personal notes, flowers, and some hard liquor. On Mon, May 19, 2014 at 5:12 PM, Kurt H Maier k...@sciops.net wrote: Quoting andrey mirtchovski mirtchov...@gmail.com: golang-dev has more clout than 9fans nowadays, at least as it pertains to plan9. That's why I'm asking. We now

Re: [9fans] syscall 53

2014-05-19 Thread Jeff Sickel
On May 19, 2014, at 6:17 PM, andrey mirtchovski mirtchov...@gmail.com wrote: I suggest personal notes, flowers, and some hard liquor. /me could use all three after a weekend of sysadmin frustration. All hope is not lost… this exercise, by not being able to use my usual cpu servers, gave me

Re: [9fans] waitfree

2014-05-19 Thread Devon H. O'Dell
2014-05-19 18:05 GMT-04:00 erik quanstrom quans...@quanstro.net: On Mon May 19 17:02:57 EDT 2014, devon.od...@gmail.com wrote: So you seem to be worried that N processors in a tight loop of LOCK XADD could have a single processor. This isn't a problem because locked instructions have total

Re: [9fans] waitfree

2014-05-19 Thread erik quanstrom
It is an ordering, but I don't think it's a valid one: your ellipses suggest an unbounded execution time (given the context of the discussion). I don't think that's valid because the protocol can't possibly negotiate execution for more instructions than it has space for in its pipeline.

Re: [9fans] syscall 53

2014-05-19 Thread cinap_lenrek
added the syscall for binary compatibility with sources to 9front kernel. nsec() remains a library function that reads /dev/bintime. removed the filedescriptor caching from nsec() like in the 9atom version. -- cianp