FAQ
Hello,

Problem: parallel benchmarking gives totally flaky results today.
When I run with explicitly specified affinity, I get reliable numbers:

$ taskset -c 0-7 go test -run=none -bench=MutexSlack -cpu=8,8,8
-benchtime=2s sync
BenchmarkMutexSlack-8 20000000 164 ns/op
BenchmarkMutexSlack-8 20000000 164 ns/op
BenchmarkMutexSlack-8 20000000 165 ns/op

$ taskset -c 0-3,16-19 go test -run=none -bench=MutexSlack -cpu=8,8,8
-benchtime=2s sync
BenchmarkMutexSlack-8 20000000 138 ns/op
BenchmarkMutexSlack-8 20000000 138 ns/op
BenchmarkMutexSlack-8 20000000 138 ns/op

$ taskset -c 0-3,8-11 go test -run=none -bench=MutexSlack -cpu=8,8,8
-benchtime=2s sync
BenchmarkMutexSlack-8 30000000 115 ns/op
BenchmarkMutexSlack-8 20000000 115 ns/op
BenchmarkMutexSlack-8 20000000 117 ns/op

However, when I run w/o explicit affinity, I get something in between.
And different from run to run. Numbers vary by basically +/-50%:

$ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
BenchmarkMutexSlack-8 20000000 141 ns/op
$ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
BenchmarkMutexSlack-8 20000000 162 ns/op
$ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
BenchmarkMutexSlack-8 20000000 107 ns/op

To get reliable numbers for a set of GOMAXPROCS values, I need to run
go test 3 times as:

$ taskset -c 0-7 go test -cpu=1,2,4,8
$ taskset -c 0-7,16-23 go test -cpu=16
$ taskset -c 0-31 go test -cpu=32

This is not something that Go users must do manually.

So the proposal: add -affinity flag to go test and testing package.
The flag has 3 values: "gather", "scatter" and "none", with "gather"
being the default. Gather means schedule the threads as close to each
other as possible, scatter means schedule threads as far from each
other as possible, none means don't mess with affinity (if user wants
to set affinity manually, or just test as-is). The default gather
value should suffice majority of users, so the problem will be just
magically solved for them under the hood.

Implementation: the majority of code (discovering system topology,
figuring out what is gather and scatter on this system, setting
affinity) will go into runtime package. This is required for the
NUMA-aware scheduler
(https://docs.google.com/document/u/1/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-qxM2Vp7iGwwuM/pub)
and will be the first step in that direction. Testing package will get
a minimal private interface of the form func
runtime_setAffinity(gather bool).

--
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

  • Austin Clements at Feb 22, 2015 at 2:18 am
    What's the topology of the machine you're running this on? I'm curious
    "how NUMA" it is.
    On Sat, Feb 21, 2015 at 11:45 AM, 'Dmitry Vyukov' via golang-dev wrote:

    Hello,

    Problem: parallel benchmarking gives totally flaky results today.
    When I run with explicitly specified affinity, I get reliable numbers:

    $ taskset -c 0-7 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 165 ns/op

    $ taskset -c 0-3,16-19 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op

    $ taskset -c 0-3,8-11 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 30000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 117 ns/op

    However, when I run w/o explicit affinity, I get something in between.
    And different from run to run. Numbers vary by basically +/-50%:

    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 141 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 162 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 107 ns/op

    To get reliable numbers for a set of GOMAXPROCS values, I need to run
    go test 3 times as:

    $ taskset -c 0-7 go test -cpu=1,2,4,8
    $ taskset -c 0-7,16-23 go test -cpu=16
    $ taskset -c 0-31 go test -cpu=32

    This is not something that Go users must do manually.

    So the proposal: add -affinity flag to go test and testing package.
    The flag has 3 values: "gather", "scatter" and "none", with "gather"
    being the default. Gather means schedule the threads as close to each
    other as possible, scatter means schedule threads as far from each
    other as possible, none means don't mess with affinity (if user wants
    to set affinity manually, or just test as-is). The default gather
    value should suffice majority of users, so the problem will be just
    magically solved for them under the hood.
    Benchmarks should be a window in to how a real system will perform, and I
    worry that this would give people a false impression of how their real
    code, outside of go test, will perform. If they run go test and see high
    variance, that's an indication that they may have a problem with their real
    system and should seek out a solution, such as controlling affinity. We
    could provide an -affinity flag to give them an easy way to test that
    hypothesis, but I think it needs to default to whatever their real system
    will do by default.

    Implementation: the majority of code (discovering system topology,
    figuring out what is gather and scatter on this system, setting
    affinity) will go into runtime package. This is required for the
    NUMA-aware scheduler
    (
    https://docs.google.com/document/u/1/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-qxM2Vp7iGwwuM/pub
    )
    and will be the first step in that direction. Testing package will get
    a minimal private interface of the form func
    runtime_setAffinity(gather bool).

    --
    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.
  • Dmitry Vyukov at Feb 22, 2015 at 10:38 am

    On Sun, Feb 22, 2015 at 5:18 AM, Austin Clements wrote:
    What's the topology of the machine you're running this on? I'm curious "how
    NUMA" it is.
    2 processors x 8 cores x 2 HT threads.
    This is a QPI-based system, so each processor is a NUMA node.

    --
    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.
  • Dmitry Vyukov at Feb 22, 2015 at 5:10 pm

    On Sun, Feb 22, 2015 at 5:18 AM, Austin Clements wrote:
    Benchmarks should be a window in to how a real system will perform, and I
    worry that this would give people a false impression of how their real code,
    outside of go test, will perform. If they run go test and see high
    variance, that's an indication that they may have a problem with their real
    system and should seek out a solution, such as controlling affinity.
    I agree that benchmarks should measure real performance. For -cpu=1
    and -cpu>=NCPU it works and will work this way. The question is about
    -cpu>1 and <NCPU. I use such values (e.g. -cpu=1,2,4,8,16,32) to
    assess program scalability and performance on machines of different
    sizes. That is, when I run with -cpu=4, I don't mean that I want to
    measure performance of the system running with GOMAXPROCS=4 on a
    machine with 32 hardware threads; I mean that I want to measure
    performance of the system as if it is running with GOMAXPROCS=NCPU on
    a machine with 4 CPUs. And from this point of view it is useful to
    bound the program to a single processor, and it does not indicate any
    problem with the system itself.
    We could provide an -affinity flag to give them an easy way to test that
    hypothesis, but I think it needs to default to whatever their real system
    will do by default.
    That sounds reasonable, but I afraid that nobody will set it to a
    non-default value. People will just live with flaky numbers and will
    not know about the flag and that it can be a solution to their
    problem.

    --
    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.
  • Rick Hudson at Feb 23, 2015 at 3:33 pm
    First I consider these affinity/scheduling issue an important problem
    facing the runtime and if anything deserves a flag it is in this area. That
    said, do we have any budget for the number of flags we intend to add to Go
    at each release? It is hard to argue that an ornament shouldn't be placed
    on the tree when all we are looking at is the ornament, particularly since
    we can't ever remove a flag.

    On Sun, Feb 22, 2015 at 12:09 PM, Dmitry Vyukov wrote:
    On Sun, Feb 22, 2015 at 5:18 AM, Austin Clements wrote:
    Benchmarks should be a window in to how a real system will perform, and I
    worry that this would give people a false impression of how their real code,
    outside of go test, will perform. If they run go test and see high
    variance, that's an indication that they may have a problem with their real
    system and should seek out a solution, such as controlling affinity.
    I agree that benchmarks should measure real performance. For -cpu=1
    and -cpu>=NCPU it works and will work this way. The question is about
    -cpu>1 and <NCPU. I use such values (e.g. -cpu=1,2,4,8,16,32) to
    assess program scalability and performance on machines of different
    sizes. That is, when I run with -cpu=4, I don't mean that I want to
    measure performance of the system running with GOMAXPROCS=4 on a
    machine with 32 hardware threads; I mean that I want to measure
    performance of the system as if it is running with GOMAXPROCS=NCPU on
    a machine with 4 CPUs. And from this point of view it is useful to
    bound the program to a single processor, and it does not indicate any
    problem with the system itself.
    We could provide an -affinity flag to give them an easy way to test that
    hypothesis, but I think it needs to default to whatever their real system
    will do by default.
    That sounds reasonable, but I afraid that nobody will set it to a
    non-default value. People will just live with flaky numbers and will
    not know about the flag and that it can be a solution to their
    problem.
    --
    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.
  • Dmitry Vyukov at Feb 24, 2015 at 9:26 am

    On Mon, Feb 23, 2015 at 6:33 PM, Rick Hudson wrote:
    First I consider these affinity/scheduling issue an important problem facing
    the runtime and if anything deserves a flag it is in this area. That said,
    do we have any budget for the number of flags we intend to add to Go at each
    release?
    No, we don't.
    But them message is noted.

    It is hard to argue that an ornament shouldn't be placed on the
    tree when all we are looking at is the ornament, particularly since we can't
    ever remove a flag.

    On Sun, Feb 22, 2015 at 12:09 PM, Dmitry Vyukov wrote:

    On Sun, Feb 22, 2015 at 5:18 AM, Austin Clements <austin@google.com>
    wrote:
    Benchmarks should be a window in to how a real system will perform, and
    I
    worry that this would give people a false impression of how their real
    code,
    outside of go test, will perform. If they run go test and see high
    variance, that's an indication that they may have a problem with their
    real
    system and should seek out a solution, such as controlling affinity.
    I agree that benchmarks should measure real performance. For -cpu=1
    and -cpu>=NCPU it works and will work this way. The question is about
    -cpu>1 and <NCPU. I use such values (e.g. -cpu=1,2,4,8,16,32) to
    assess program scalability and performance on machines of different
    sizes. That is, when I run with -cpu=4, I don't mean that I want to
    measure performance of the system running with GOMAXPROCS=4 on a
    machine with 32 hardware threads; I mean that I want to measure
    performance of the system as if it is running with GOMAXPROCS=NCPU on
    a machine with 4 CPUs. And from this point of view it is useful to
    bound the program to a single processor, and it does not indicate any
    problem with the system itself.
    We could provide an -affinity flag to give them an easy way to test that
    hypothesis, but I think it needs to default to whatever their real
    system
    will do by default.
    That sounds reasonable, but I afraid that nobody will set it to a
    non-default value. People will just live with flaky numbers and will
    not know about the flag and that it can be a solution to their
    problem.
    --
    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.
  • Dave Cheney at Feb 22, 2015 at 5:51 am
    Outside linux, is it possible for a user space task to alter its
    processor affinity ? I would not like to see this feature added only
    to be a noop on all but one operating system.

    On Sun, Feb 22, 2015 at 3:45 AM, 'Dmitry Vyukov' via golang-dev
    wrote:
    Hello,

    Problem: parallel benchmarking gives totally flaky results today.
    When I run with explicitly specified affinity, I get reliable numbers:

    $ taskset -c 0-7 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 165 ns/op

    $ taskset -c 0-3,16-19 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op

    $ taskset -c 0-3,8-11 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 30000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 117 ns/op

    However, when I run w/o explicit affinity, I get something in between.
    And different from run to run. Numbers vary by basically +/-50%:

    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 141 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 162 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 107 ns/op

    To get reliable numbers for a set of GOMAXPROCS values, I need to run
    go test 3 times as:

    $ taskset -c 0-7 go test -cpu=1,2,4,8
    $ taskset -c 0-7,16-23 go test -cpu=16
    $ taskset -c 0-31 go test -cpu=32

    This is not something that Go users must do manually.

    So the proposal: add -affinity flag to go test and testing package.
    The flag has 3 values: "gather", "scatter" and "none", with "gather"
    being the default. Gather means schedule the threads as close to each
    other as possible, scatter means schedule threads as far from each
    other as possible, none means don't mess with affinity (if user wants
    to set affinity manually, or just test as-is). The default gather
    value should suffice majority of users, so the problem will be just
    magically solved for them under the hood.

    Implementation: the majority of code (discovering system topology,
    figuring out what is gather and scatter on this system, setting
    affinity) will go into runtime package. This is required for the
    NUMA-aware scheduler
    (https://docs.google.com/document/u/1/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-qxM2Vp7iGwwuM/pub)
    and will be the first step in that direction. Testing package will get
    a minimal private interface of the form func
    runtime_setAffinity(gather bool).

    --
    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.
  • Brainman at Feb 22, 2015 at 6:38 am

    On Sunday, 22 February 2015 16:51:58 UTC+11, Dave Cheney wrote:
    Outside linux, is it possible for a user space task to alter its
    processor affinity ?
    There is windows SetThreadAffinityMask and others.

    Alex

    --
    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.
  • Dmitry Vyukov at Feb 22, 2015 at 10:33 am
    Linux and Windows has full support for affinity and topology discovery.
    I see that FreeBSD has cpuset_setaffinity:
    http://www.polarhome.com/service/man/?qf=cpuset_setaffinity&tf=2&of=FreeBSD&sf=2
    Darwin also seems to have something:
    https://developer.apple.com/library/mac/releasenotes/Performance/RN-AffinityAPI/#//apple_ref/doc/uid/TP40006635-CH1-DontLinkElementID_2
    Don't know about the rest.

    On Sun, Feb 22, 2015 at 8:51 AM, Dave Cheney wrote:
    Outside linux, is it possible for a user space task to alter its
    processor affinity ? I would not like to see this feature added only
    to be a noop on all but one operating system.

    On Sun, Feb 22, 2015 at 3:45 AM, 'Dmitry Vyukov' via golang-dev
    wrote:
    Hello,

    Problem: parallel benchmarking gives totally flaky results today.
    When I run with explicitly specified affinity, I get reliable numbers:

    $ taskset -c 0-7 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 165 ns/op

    $ taskset -c 0-3,16-19 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op

    $ taskset -c 0-3,8-11 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 30000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 117 ns/op

    However, when I run w/o explicit affinity, I get something in between.
    And different from run to run. Numbers vary by basically +/-50%:

    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 141 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 162 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 107 ns/op

    To get reliable numbers for a set of GOMAXPROCS values, I need to run
    go test 3 times as:

    $ taskset -c 0-7 go test -cpu=1,2,4,8
    $ taskset -c 0-7,16-23 go test -cpu=16
    $ taskset -c 0-31 go test -cpu=32

    This is not something that Go users must do manually.

    So the proposal: add -affinity flag to go test and testing package.
    The flag has 3 values: "gather", "scatter" and "none", with "gather"
    being the default. Gather means schedule the threads as close to each
    other as possible, scatter means schedule threads as far from each
    other as possible, none means don't mess with affinity (if user wants
    to set affinity manually, or just test as-is). The default gather
    value should suffice majority of users, so the problem will be just
    magically solved for them under the hood.

    Implementation: the majority of code (discovering system topology,
    figuring out what is gather and scatter on this system, setting
    affinity) will go into runtime package. This is required for the
    NUMA-aware scheduler
    (https://docs.google.com/document/u/1/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-qxM2Vp7iGwwuM/pub)
    and will be the first step in that direction. Testing package will get
    a minimal private interface of the form func
    runtime_setAffinity(gather bool).

    --
    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 Feb 27, 2015 at 2:15 am
    I don't believe we understand this anywhere near well enough to be talking
    about adding new flags to go test and the testing package. It may be that
    the runtime needs to understand affinity correctly and do the right thing
    automatically, but that's a lot different than adding a flag. Adding new
    flags is not something to be done lightly.

    Clearly you have an external command that can set affinity (taskset in your
    examples). For now I would say keep setting it that way, learn what we can
    about how things should work, and then make them work the right way by
    default.

    Thanks.
    Russ
    On Sat, Feb 21, 2015 at 11:45 AM, Dmitry Vyukov wrote:

    Hello,

    Problem: parallel benchmarking gives totally flaky results today.
    When I run with explicitly specified affinity, I get reliable numbers:

    $ taskset -c 0-7 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 164 ns/op
    BenchmarkMutexSlack-8 20000000 165 ns/op

    $ taskset -c 0-3,16-19 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op
    BenchmarkMutexSlack-8 20000000 138 ns/op

    $ taskset -c 0-3,8-11 go test -run=none -bench=MutexSlack -cpu=8,8,8
    -benchtime=2s sync
    BenchmarkMutexSlack-8 30000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 115 ns/op
    BenchmarkMutexSlack-8 20000000 117 ns/op

    However, when I run w/o explicit affinity, I get something in between.
    And different from run to run. Numbers vary by basically +/-50%:

    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 141 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 162 ns/op
    $ go test -run=none -bench=MutexSlack -cpu=8 -benchtime=2s sync
    BenchmarkMutexSlack-8 20000000 107 ns/op

    To get reliable numbers for a set of GOMAXPROCS values, I need to run
    go test 3 times as:

    $ taskset -c 0-7 go test -cpu=1,2,4,8
    $ taskset -c 0-7,16-23 go test -cpu=16
    $ taskset -c 0-31 go test -cpu=32

    This is not something that Go users must do manually.

    So the proposal: add -affinity flag to go test and testing package.
    The flag has 3 values: "gather", "scatter" and "none", with "gather"
    being the default. Gather means schedule the threads as close to each
    other as possible, scatter means schedule threads as far from each
    other as possible, none means don't mess with affinity (if user wants
    to set affinity manually, or just test as-is). The default gather
    value should suffice majority of users, so the problem will be just
    magically solved for them under the hood.

    Implementation: the majority of code (discovering system topology,
    figuring out what is gather and scatter on this system, setting
    affinity) will go into runtime package. This is required for the
    NUMA-aware scheduler
    (
    https://docs.google.com/document/u/1/d/1d3iI2QWURgDIsSR6G2275vMeQ_X7w-qxM2Vp7iGwwuM/pub
    )
    and will be the first step in that direction. Testing package will get
    a minimal private interface of the form func
    runtime_setAffinity(gather bool).
    --
    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
postedFeb 21, '15 at 4:45p
activeFeb 27, '15 at 2:15a
posts10
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase