On 16/05/2019 14:30, Andrii Anisov wrote:
Hello Jan,
On 16.05.19 15:09, Jan Beulich wrote:
On 23.04.19 at 10:10, <andrii.ani...@gmail.com> wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -163,15 +163,23 @@ struct vcpu
void *sched_priv; /* scheduler-specific data */
struct vcpu_runstate_info runstate;
+
+ spinlock_t mapped_runstate_lock;
Besides other comments given elsewhere already - does this
really need to be a per-vCPU lock? Guests aren't expected to
invoke the API frequently, so quite likely a per-domain lock
would suffice. Quite possibly domain_{,un}lock() could
actually be (re-)used.
I'd not use a per-domain lock here. This lock will be locked on every runstate
area update, what's happening on every context switch. And the event of
simultaneous switching of several vcpus from the same domain has quite high
probability.
The lock can be completely removed anyway. See my previous comments.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
