> 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
> 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 t
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
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 imp
> 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 mat
> 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 ch
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 i
On 19 May 2014 18:13, 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 to cache the time
> > 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
>
> On 19 May 2014 18:13, 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 to ca
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 says
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 an
On 19 May 2014 20:15, Aram Hăvărneanu 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 troublesome in
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 wh
On Mon, 19 May 2014 13:25:42 EDT erik quanstrom 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 time and accuracy
> 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 s
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 ato
> 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 (al
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 w
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 instruc
On 19 May 2014 21:54, ron minnich 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 scheduling. When there
is
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
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 scheduling. When there
>
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 tha
On Mon, May 19, 2014 at 3:05 PM, erik quanstrom 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 somewhere in the works.
ron
On Mon May 19 18:15:21 EDT 2014, rminn...@gmail.com wrote:
> On Mon, May 19, 2014 at 3:05 PM, erik quanstrom 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!
>
Quoting ron minnich :
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 request to reex
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 wrote:
> Quoting ron minnich :
>
>> 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
Quoting andrey mirtchovski :
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. I'm not complaining;
I suggest personal notes, flowers, and some hard liquor.
On Mon, May 19, 2014 at 5:12 PM, Kurt H Maier wrote:
> Quoting andrey mirtchovski :
>
>> 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 sys
On May 19, 2014, at 6:17 PM, andrey mirtchovski 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 time to cut over to
2014-05-19 18:05 GMT-04:00 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
> 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. F
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
33 matches
Mail list logo
