[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: Andrii Anisov <andrii.anisov@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>
- From: Julien Grall <julien.grall@xxxxxxx>
- Date: Thu, 16 May 2019 14:48:37 +0100
- 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, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "andrii_anisov@xxxxxxxx" <andrii_anisov@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Thu, 16 May 2019 13:48:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.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.
The lock can be completely removed anyway. See my previous comments.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
