3 ms·
This matches my experience: Linux is very good at maximizing throughput, even when significantly over-subscribed. Two broad gotchas: - If the "task workflow"
by twoodfin 6y ago
This matches my experience: Linux is very good at maximizing throughput, even when significantly over-subscribed.
Two broad gotchas:
- If the "task workflow" of an application involves a pipeline of N threads performing logically connected operations in sequence, the direct and indirect cost of N context switches is going to put a lower bound on latency and resource consumption for each task. This gets worse if the N threads aren't all in the same process, and TLB flushes enter the picture.
- Without careful priority tuning, at high levels of over-subscription, latency becomes highly variable, as you saw in an interactive shell. There's no free lunch; if you want predictable latency you need to reserve cycles that would otherwise be available to maximize throughput.
- the8472 6y ago> Without careful priority tuning Which might be as simple as marking the throughput tasks as SCHED_BATCH. It'll make their latency even worse but preserve throughput, give priority to the shell and reduce context switches on an oversubscribed system even further. Or you could use taskset/cgroups to reserve 1 hyperthread for interactive things.
- gnulinux 6y agoIf you assign maximum niceness to worker threads, and minimum niceness to all threads that deal with your shell (i.e. bash or ssh etc) does it improve the predictability of latency? A couple years ago I tried to do something like this really quick, but wasn't able to get good latency. I'm wondering if it's possible if you do it right.
- ploxiln 6y agoThese days, niceness is considered not adequate for this kind of thing ... you should get better results if you put all the worker threads in one cgroup, and your ssh/shell in another cgroup, with the cpu group scheduler enabled, and this should keep fairness for your interactive shell.