[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: Andrii Anisov <andrii.anisov@xxxxxxxxx>
- Date: Thu, 16 May 2019 16:30:51 +0300
- Cc: Tim Deegan <tim@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Julien Grall <julien.grall@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "andrii_anisov@xxxxxxxx" <andrii_anisov@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Thu, 16 May 2019 13:30:57 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hello Jan,
On 16.05.19 15:09, Jan Beulich wrote:
On 23.04.19 at 10:10, <andrii.anisov@xxxxxxxxx> 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.
--
Sincerely,
Andrii Anisov.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
