Skip to contentSkip to conversation

Is there a plan to introduce a unified co-scheduling mechanism to CFS ?

question Zhang Haoyu 2 participants 3 messages Oct 10, 2014 KVM

lore
Share & tools
lore
#0 lore raw

Hi,

Is it worthy to introduce a unified co-scheduling mechanism to CFS ?
Because multiple cooperating threads or tasks frequently synchronize with each other,
not executing them concurrently would only increase the latency of synchronization.
For example, a thread blocking in spinlock to waiting for another thread to release the same spinlock might reduce its waiting time by being executed concurrently with the thread which hold the same spinlock. In virtualization scenario, multiple vcpus (which belong to the same vm) co-scheduling is more desired when several cooperating threads/task is running in guest.

Is there a plane for this work?

Thanks,
Zhang Haoyu

#1 lore raw
Quoted 11 lines · Zhang Haoyu

Hi,

Is it worthy to introduce a unified co-scheduling mechanism to CFS ?
Because multiple cooperating threads or tasks frequently synchronize with each other,
not executing them concurrently would only increase the latency of synchronization.
For example, a thread blocking in spinlock to waiting for another thread to release the same spinlock might reduce its waiting time by being executed concurrently with the thread which hold the same spinlock. In virtualization scenario, multiple vcpus (which belong to the same vm) co-scheduling is more desired when several cooperating threads/task is running in guest.

Is there a plane for this work?

Please refer to gang scheduler.

Regards,
Wanpeng Li

Quoted 7 lines

Thanks,
Zhang Haoyu

Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
#2 lore raw
Quoted 10 lines
Quoted 10 lines

Hi,

Is it worthy to introduce a unified co-scheduling mechanism to CFS ?
Because multiple cooperating threads or tasks frequently synchronize with each other,
not executing them concurrently would only increase the latency of synchronization.
For example, a thread blocking in spinlock to waiting for another thread to release the same spinlock might reduce its waiting time by being executed concurrently with the thread which hold the same spinlock. In virtualization scenario, multiple vcpus (which belong to the same vm) co-scheduling is more desired when several cooperating threads/task is running in guest.

Quoted 4 lines
Quoted 1 line

Is there a plane for this work?

Please refer to gang scheduler.

Is there a mechanism to dynamically detect which vcpus belong to the same gang?
Maybe a cooperative degree can be used to decide the threshold of which vcpus belong to the same gang, just a wild thought.

Quoted 5 lines

Regards,
Wanpeng Li

Quoted 3 lines

Thanks,
Zhang Haoyu