thread_affinity_set(CPU_CURRENT) can skip cpu_lock
When setting a thread's affinity to the CPU it's currently executing on, thread_affinity_set takes cpu_lock, presumably to avoid situations where migrations and/or CPU offlining behavior causes the affinity election to become invalid over the course of the call. While setting affinity to a CPU other than the active one obviously requires cpu_lock (as once asserted by the thread_affinity_set logic), but setting affinity to the current CPU should simply require kpreempt_disable to ensure that the CPU is not grabbed out from under the thread during the operation.
This improvement would reduce contention on cpu_lock for threads wanting to set the affinity more frequently (such as desired by bhyve, for example).
Updated by Electric Monk 5 months ago
- % Done changed from 0 to 100
- Status changed from New to Closed
commit cfbda96766a25458b8ad2be1a09a59ce247a25d8 Author: Patrick Mooney <firstname.lastname@example.org> Date: 2019-05-14T17:51:20.000Z 10923 thread_affinity_set(CPU_CURRENT) can skip cpu_lock Reviewed by: Jerry Jelinek <email@example.com> Reviewed by: John Levon <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>