Hacker News Reader

Comment by im3w1l | Hacker News Reader

Single core computers yes. Single core containers though..

Single core containers are also a terrible idea. Life got much less deadlocked as soon as there were 2+ processors everywhere.

(Huh, people like hard OS design problems for marginal behavior? OSes had trouble adopting SMP but we also got to jettison a lot of deadlock discussions as soon as there was CPU 2. It only takes a few people not prioritizing 1 CPU testing at any layer to make your 1 CPU container much worse than a 2 VCPU container limited to a 1 CPU average.)

It's actually quite difficult to get a "single core" container (ie: a container with access to only one logical processor).

When you set "request: 1" in Kubernetes or another container manager, you're saying "give me 1 CPU worth of CPU time" but if the underlying Linux host has 16 logical cores your container will still see them.

Your container is free to use 1/16th of each of them, 100% of one of them, or anything in-between.

You might think this doesn't matter in the end but it can if you have a lot of workloads on that node and those cores are busy. Your single threaded throughout can become quite compromised as a result.

> if you have a lot of workloads on that node and those cores are busy. Your single threaded throughout can become quite compromised as a result.

While yes this can cause a slowdown, wouldn't it still happen if each container thought it had a single core?

Only if you have more containers than cores.

That depends on what your scheduler does. Having one virtual core doesn't necessarily mean you always get the same physical core.

Also you said "a lot of workloads" so yes probably more containers than cores.

Most of my pods have a CPU request >= 1 so more containers than cores is rare. But obviously that really depends on your workload(s).

I don't think the scheduler picking a different core matters much unless your workload is super cache sensitive. My point is more about access to single threaded performance. If you have a single threaded workload (ex: an ffmpeg audio encode) and you want it to be able to access as many cycles from a single core as possible, it isn't always as simple as request: 1

It's easy, though?

On Docker, --cpuset-cpus=0 will pin the container to the first core.

K8s: https://kubernetes.io/docs/tasks/administer-cluster/cpu-mana...

CPU affinity and pinning is something I think you should be able to achieve without too much hassle.

I think the point was this isn’t the norm though. If you know you need to be pinned to a core you CAN configure kubernetes to do so but it’s not the default and therefore you are unknowingly leaving performance on the floor

I'm quite certain you'd leave more performance on the table by pinning in general and on average.

Just let the CPU scheduler do its job. Unless you know better, in which case, by all means go ahead and allocate computational resources manually. I don't see a way to make that a sensible default, though.

> It's easy though

Neat, I didn't know it was a single flag in Docker.

The k8s method you linked definitely has some caveats as it doesn't allow this scheduling at the pod level, and requires quite a bit of fiddling to get working (atleast on GKE). This isn't even available if you use a fully managed setup like autopilot.

Maybe my expectations just aren't realistic but "easy" to me would mean I put the affinity right next to my CPU request in the podSpec :/

Reply on news.ycombinator.com