FAQ
I've got a go1.5 toolchain and I'm running go build on a plan 9 system (but
one which supports ELF binaries).

When running the go build on the plan 9 system, the link step takes a long
time. One thing I see that I don't quite understand is that out of the
69,000 or so system calls, 32000 of them are seek(fd, 0, 1). These occur
while a child process is doing 10 millisecond sleeps.

The last thing it does on this fd is write 5 bytes at the end, seek to 0,
and write a 24 byte ELF header, then close it.

I'm pretty sure this call is originating out of Cpos().

I'm sorry this is so nonspecific, but I'm hoping this might tickle
someone's memory. Is the continued seek some sort of poor man's inotify
replacement, or fsync, or ...?

ron

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Dec 17, 2015 at 7:40 pm
    I think it's just a bad translation from C.

    Dave Cheney had a CL to clean some of this up but it didn't make it for Go
    1.6.

    On Thu, Dec 17, 2015 at 11:34 AM, ron minnich wrote:

    I've got a go1.5 toolchain and I'm running go build on a plan 9 system
    (but one which supports ELF binaries).

    When running the go build on the plan 9 system, the link step takes a long
    time. One thing I see that I don't quite understand is that out of the
    69,000 or so system calls, 32000 of them are seek(fd, 0, 1). These occur
    while a child process is doing 10 millisecond sleeps.

    The last thing it does on this fd is write 5 bytes at the end, seek to 0,
    and write a 24 byte ELF header, then close it.

    I'm pretty sure this call is originating out of Cpos().

    I'm sorry this is so nonspecific, but I'm hoping this might tickle
    someone's memory. Is the continued seek some sort of poor man's inotify
    replacement, or fsync, or ...?

    ron

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Dec 17, 2015 at 7:44 pm

    On Thu, Dec 17, 2015 at 11:34 AM, ron minnich wrote:
    I've got a go1.5 toolchain and I'm running go build on a plan 9 system (but
    one which supports ELF binaries).

    When running the go build on the plan 9 system, the link step takes a long
    time. One thing I see that I don't quite understand is that out of the
    69,000 or so system calls, 32000 of them are seek(fd, 0, 1). These occur
    while a child process is doing 10 millisecond sleeps.

    The last thing it does on this fd is write 5 bytes at the end, seek to 0,
    and write a 24 byte ELF header, then close it.

    I'm pretty sure this call is originating out of Cpos().

    I'm sorry this is so nonspecific, but I'm hoping this might tickle someone's
    memory. Is the continued seek some sort of poor man's inotify replacement,
    or fsync, or ...?
    I expect that most or all of those seeks come from calls to
    obj.Boffset in cmd/link/internal/ld. Many of those calls are just
    pointless, like ldobj which calls it twice in a row for no reason.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Dec 17, 2015 at 8:12 pm
    I think it's also because cmd/link's idiomatic way of generating
    cross-references or measuring the size of blobs just involves lots of calls
    to Cpos? E.g., things like:

         start := Cpos()
         writesomestuff()
         size := Cpos() - start
         emitcrossreference(start, size)

    Anyway, as a quick experiment, I prepared a CL (https://golang.org/cl17917)
    to cache the file offset in userland so ld.Cpos doesn't need to make any
    system calls. strace -c -f shows this reduces the number of lseek systems
    calls during linking cmd/compile from 99k to 11k, and supposedly this
    reduces CPU time by about 0.08s (about 0.3%).

    Doesn't seem significant on my workstation, but maybe it's more noticeable
    on slower machines.
    On Thu, Dec 17, 2015 at 11:44 AM, Ian Lance Taylor wrote:
    On Thu, Dec 17, 2015 at 11:34 AM, ron minnich wrote:
    I've got a go1.5 toolchain and I'm running go build on a plan 9 system (but
    one which supports ELF binaries).

    When running the go build on the plan 9 system, the link step takes a long
    time. One thing I see that I don't quite understand is that out of the
    69,000 or so system calls, 32000 of them are seek(fd, 0, 1). These occur
    while a child process is doing 10 millisecond sleeps.

    The last thing it does on this fd is write 5 bytes at the end, seek to 0,
    and write a 24 byte ELF header, then close it.

    I'm pretty sure this call is originating out of Cpos().

    I'm sorry this is so nonspecific, but I'm hoping this might tickle someone's
    memory. Is the continued seek some sort of poor man's inotify
    replacement,
    or fsync, or ...?
    I expect that most or all of those seeks come from calls to
    obj.Boffset in cmd/link/internal/ld. Many of those calls are just
    pointless, like ldobj which calls it twice in a row for no reason.

    Ian

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Dec 17, 2015 at 8:20 pm

    On Thu, Dec 17, 2015 at 3:12 PM, 'Matthew Dempsky' via golang-dev wrote:

    Doesn't seem significant on my workstation, but maybe it's more noticeable
    on slower machines.
    Or slower operating systems. :-)

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ron minnich at Dec 17, 2015 at 8:28 pm

    On Thu, Dec 17, 2015 at 12:20 PM Russ Cox wrote:
    Or slower operating systems. :-)
    yep. And I'm not sure that 39K seeks was a factor, I just found it
    surprising.

    Thanks all!

    ron

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Dec 17, 2015 at 9:11 pm

    On Thu, Dec 17, 2015 at 12:20 PM, Russ Cox wrote:

    Or slower operating systems. :-)
    Repeating the test on my slower OpenBSD workstation shows similar (i.e.,
    negligible) results as on my fast Linux one. So it must require *even
    slower* machines and/or OSes!

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ron minnich at Dec 17, 2015 at 10:12 pm
    Yeah, I don't think that's the problem, it just surprised me to see 39K
    seeks, one after the other, to the same place.

    The only thing it slows down, it seems, is printing trace data
    ;-)

    ron
    On Thu, Dec 17, 2015 at 1:11 PM Matthew Dempsky wrote:
    On Thu, Dec 17, 2015 at 12:20 PM, Russ Cox wrote:

    Or slower operating systems. :-)
    Repeating the test on my slower OpenBSD workstation shows similar (i.e.,
    negligible) results as on my fast Linux one. So it must require *even
    slower* machines and/or OSes!
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 17, '15 at 7:34p
activeDec 17, '15 at 10:12p
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase