[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 08/48] xen/sched: switch vcpu_schedule_lock to unit_schedule_lock
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Juergen Gross <jgross@xxxxxxxx>
- Date: Wed, 4 Sep 2019 17:02:59 +0200
- Cc: Tim Deegan <tim@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Meng Xu <mengxu@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 04 Sep 2019 15:03:10 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 04.09.19 16:54, Jan Beulich wrote:
On 04.09.2019 16:41, Juergen Gross wrote:
On 04.09.19 16:02, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -250,7 +250,8 @@ static inline void vcpu_runstate_change(
void vcpu_runstate_get(struct vcpu *v, struct vcpu_runstate_info *runstate)
{
- spinlock_t *lock = likely(v == current) ? NULL : vcpu_schedule_lock_irq(v);
+ spinlock_t *lock = likely(v == current)
+ ? NULL : unit_schedule_lock_irq(v->sched_unit);
s_time_t delta;
memcpy(runstate, &v->runstate, sizeof(*runstate));
@@ -259,7 +260,7 @@ void vcpu_runstate_get(struct vcpu *v, struct
vcpu_runstate_info *runstate)
runstate->time[runstate->state] += delta;
if ( unlikely(lock != NULL) )
- vcpu_schedule_unlock_irq(lock, v);
+ unit_schedule_unlock_irq(lock, v->sched_unit);
}
At the example of this: The more coarse granularity of the lock
means that no two vCPU-s within a unit can obtain their runstate
in parallel. While this may be acceptable for core scheduling,
I'm afraid it's too restrictive for sockets or nodes as units.
Therefore I think this lock needs to either be split (I'm not
sure that's feasible) or become an r/w lock.
You are aware that even today with credit2 all cpus of a socket share
the same lock (if not modified via boot parameter)?
No, I wasn't (explicitly; I could have deduced it). Not very helpful,
I'm afraid, but unlikely to be bad enough to go back to credit1 (but
people having an issue with this could be told to switch back).
Well, performance tests have shown that this is the most performant
setting. And before going back to credit1 they still can use another
lock setting (core or cpu).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
