On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19 7:40 AM, Juergen Gross wrote:
sched_tick_suspend() and sched_tick_resume() should not call the
scheduler specific timer handlers in case the cpu they are running on
is just being moved to or from a cpupool.
Use a new percpu lock for that purpose.
Is there a reason we can't use the pcpu_schedule_lock() instead of
introducing a new one? Sorry if this is obvious, but it's been a while
since I poked around this code.
Lock contention would be higher especially with credit2 which is using a
per-core or even per-socket lock. We don't care about other scheduling
activity here, all we need is a guard against our per-cpu scheduler
data being changed beneath our feet.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel