On Thu, 22 Oct 2020 20:29:42 -0700 Josh Don wrote: > Busy polling loops in the kernel such as network socket poll and kvm > halt polling have performance problems related to process scheduler load > accounting. > > Both of the busy polling examples are opportunistic - they relinquish > the cpu if another thread is ready to run. That makes it sound like the busy poll code is trying to behave like an idle task. I thought need_resched() meant we leave when we run out of slice, or kernel needs to go through a resched for internal reasons. No? > This design, however, doesn't > extend to multiprocessor load balancing very well. The scheduler still > sees the busy polling cpu as 100% busy and will be less likely to put > another thread on that cpu. In other words, if all cores are 100% > utilized and some of them are running real workloads and some others are > running busy polling loops, newly woken up threads will not prefer the > busy polling cpus. System wide throughput and latency may suffer. IDK how well this extends to networking. Busy polling in networking is a conscious trade-off of CPU for latency, if application chooses to busy poll (which isn't the default) we should respect that. Is your use case primarily kvm?
