undefined | Better HN

story

0 pointslcof1y ago0 comments

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

0 comments

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

lcofOP1y 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

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

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

j / k navigate · click thread line to collapse

0 comments

kbolino1y ago

However, as far as I can tell, there's no clear way to figure out what M is, in the general case.

lcofOP1y ago

kbolino1y ago

trws1y ago

j / k navigate · click thread line to collapse