- During a spin locks
- When there is no a thread in ready state
- When there is no thread
- When threads only poll a variable
First, I tackled case 1 by introducing the pause instruction inside the loop. This relaxes the CPU when a thread is getting exclusive access to a resource. Cases 2 and 3 were improved by using hlt which just halts the CPU until next interruption. To tackle case 4, I proposed two APIs to tell the scheduler when a thread is polling a variable. When scheduler figures out that all threads in a core are polling a variable, it just turns the core off.
I tested this in my baremetal host (4 cores, 8 GB, 2GHz) in Scaleway with KVM and a VM running Toro. I also installed Monitorix to monitor the state of the host. To stress the system, I generate http traffic and monitor the CPU usage. A few seconds after the stress stopped, the CPU usage of the qemu process is only about 1%. This usage goes up and down depending on the stress. By topping, I get a patter like this:
CPU%
6.6 0.6 0:46.92 qemu-system-x86
63.8 0.6 0:48.84 qemu-system-x86 (stress)
99.7 0.6 0:51.84 qemu-system-x86 (stress)
45.5 0.6 0:53.21 qemu-system-x86 (stress)
2.3 0.6 0:53.28 qemu-system-x86
4.0 0.6 0:53.40 qemu-system-x86
6.6 0.6 0:53.60 qemu-system-x86
[1] https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/IdleTalk.pdf
[2] Intel Volume 3, section 8.10.2 and 8.10.4
No comments:
Post a Comment