6 ms·

On Linux, go uses sched_getaffinity to know how many cpu core it is allowed to run on: https://cs.opensource.google/go/go/+/master:src/runtime/os_linux.go;l=97

by lcof 2y ago

On Linux, go uses sched_getaffinity to know how many cpu core it is allowed to run on: https://cs.opensource.google/go/go/+/master:src/runtime/os_linux.go;l=97 https://cs.opensource.google/go/go/+/master:src/runtime/os_l...

eadmund 2y ago
> > On servers with 100+ cores I have seen scheduling time take over 10% of the program runtime. > On Linux, go uses sched_getaffinity … Since cgroups are a Linux-only feature, OP must be running Linux. I wonder if his experience pre-dates Go’s usage of sched_getaffinity. edit: I realised that he references cgroups so must be on Linux.
Thaxll 2y ago
This is not group aware.
- lcof 2y ago
  if you want to limit the number of Ps, then you use a cpuset, that sched_getaffinity will take into account. cgroups only allows you to limit cpu usage, but not lower the number of cpu cores the code can run on. This is “how many” versus “how much”, and GOMAXPROCS only relates to the “how many” part. I may have misunderstood the rationale here, but I think the discussion about cgroup support is not about limiting the number of Ps
  - kbolino 2y ago
    What people want is that, if cgroup limits prevent a container from using more than M/N of CPU time (N the number of cores), then GOMAXPROCS defaults to M. Ditto other managed language runtimes and their equivalent parameters. However, as far as I can tell, there's no clear way to figure out what M is, in the general case.
    - lcof 2y ago
      Again, I might be wrong as I did not use this directly in a couple years, but saying “the limit is 50% share of 10 cores” is not equivalent to “the limit is 5 cores”. This is still “how much” versus “how many”, and cannot translate into each other without sacrificing flexibility
      - kbolino 2y ago
        GOMAXPROCS sets the number of live system threads used to run goroutines. The distinction between 50% of time on 10 cores and 100% of time on 5 cores doesn't really matter here: the recommendation is to set GOMAXPROCS=5 in both cases.
  - trws 2y ago
    I think your comment was once completely correct, but there is now also a “cpuset” cgroup in addition to the classic cpu setting. The cpuset control gives something equivalent to sched_setaffinity but stronger since the client processes can’t unset parts of the mask or override it IIRC.

by lcof 2y ago

eadmund 2y ago

> > On servers with 100+ cores I have seen scheduling time take over 10% of the program runtime. > On Linux, go uses sched_getaffinity … Since cgroups are a Linux-only feature, OP must be running Linux. I wonder if his experience pre-dates Go’s usage of sched_getaffinity. edit: I realised that he references cgroups so must be on Linux.

Thaxll 2y ago

This is not group aware.

lcof 2y ago
if you want to limit the number of Ps, then you use a cpuset, that sched_getaffinity will take into account. cgroups only allows you to limit cpu usage, but not lower the number of cpu cores the code can run on. This is “how many” versus “how much”, and GOMAXPROCS only relates to the “how many” part. I may have misunderstood the rationale here, but I think the discussion about cgroup support is not about limiting the number of Ps
- kbolino 2y ago
  What people want is that, if cgroup limits prevent a container from using more than M/N of CPU time (N the number of cores), then GOMAXPROCS defaults to M. Ditto other managed language runtimes and their equivalent parameters. However, as far as I can tell, there's no clear way to figure out what M is, in the general case.
  - lcof 2y ago
    Again, I might be wrong as I did not use this directly in a couple years, but saying “the limit is 50% share of 10 cores” is not equivalent to “the limit is 5 cores”. This is still “how much” versus “how many”, and cannot translate into each other without sacrificing flexibility
    - kbolino 2y ago
      GOMAXPROCS sets the number of live system threads used to run goroutines. The distinction between 50% of time on 10 cores and 100% of time on 5 cores doesn't really matter here: the recommendation is to set GOMAXPROCS=5 in both cases.
- trws 2y ago
  I think your comment was once completely correct, but there is now also a “cpuset” cgroup in addition to the classic cpu setting. The cpuset control gives something equivalent to sched_setaffinity but stronger since the client processes can’t unset parts of the mask or override it IIRC.