Project

General

Profile

Bug #10923

thread_affinity_set(CPU_CURRENT) can skip cpu_lock

Added by John Levon 6 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2019-05-07
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

http://smartos.org/bugview/OS-6698

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).

History

#1

Updated by Electric Monk 5 months ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit cfbda96766a25458b8ad2be1a09a59ce247a25d8

commit  cfbda96766a25458b8ad2be1a09a59ce247a25d8
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2019-05-14T17:51:20.000Z

    10923 thread_affinity_set(CPU_CURRENT) can skip cpu_lock
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: John Levon <john.levon@joyent.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Also available in: Atom PDF