[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] x86/vpt: Do not take pt_migrate rwlock in some cases


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • Date: Mon, 29 Mar 2021 11:31:28 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vktUX/LWramEoiCqY3+yz9Yv08/2+qVPBy8xEj2nPZY=; b=erbmwNUI6n2JbjgBUL67iZz49vRRar/nKi89VcTHB8AhIdV6xtCtacFtR9ANRItBuqERPUAU8Y4ESx0tatZbk8OimrtLNfvZ5da0wZxb5Gy3k2eEjlwoCUFacDcQxYHA6EuthJVQlV3migqSAx8Of0+Au0adQAXlbw056MjUtYDatfK14VDpmVKNIqfWEmG8wn4r2i/cxNlX3OUmL9TYGc9ulhizDUYBBQ6oYBzgPED5lMG15MdaC8Xhv1s5vwTar0nmBJyRga+DQVz/gnHkHo5zmzMmPx6IKORR3oSWwgldPiSj5jlbkIup4y0qQwArmxbkIg1YPByCI2iifR3foA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wl2fuSxT08N6ouZ75BIswmbGqYaM3CMNXgArTolj+774EOOLT/lvxwNDVMcy7lNoFb3l7GKSM5fcuoVGng75+IThvZX/JIHLMYGlYliBPTN0xsuCITbt3cS0OQooRO9/zegjTvB/Md1FxNXrJ8lFvo2Kv3zOe/sgjSOPLyNH3Z9n7O7dd6kmbZjmBylUKZ3nnkdMW11tvhxX47uygvUOGCv8O8eJVJUCuFVya5SOlfGxAY1C05yztX7JUdLyp8R+6XMYvbw/OG+pI7BtswckN5KZL3FmXCbVwJkSwk4vRkEPt+zOU353ssnaOzQhn328lSGFQGNJ0c1P0jFdgkUvvw==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=oracle.com;
  • Cc: andrew.cooper3@xxxxxxxxxx, wl@xxxxxxx, stephen.s.brennan@xxxxxxxxxx, iwj@xxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, roger.pau@xxxxxxxxxx
  • Delivery-date: Mon, 29 Mar 2021 15:31:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 3/29/21 11:21 AM, Jan Beulich wrote:
> On 29.03.2021 17:04, Boris Ostrovsky wrote:
>> On 3/29/21 5:56 AM, Jan Beulich wrote:
>>> On 27.03.2021 02:51, Boris Ostrovsky wrote:
>>>> @@ -580,13 +593,22 @@ static void pt_adjust_vcpu(struct periodic_time *pt, 
>>>> struct vcpu *v)
>>>>          return;
>>>>  
>>>>      write_lock(&pt->vcpu->domain->arch.hvm.pl_time->pt_migrate);
>>>> +
>>>> +    pt_vcpu_lock(pt->vcpu);
>>>> +    if ( pt->on_list )
>>>> +        list_del(&pt->list);
>>>> +    pt_vcpu_unlock(pt->vcpu);
>>> While these two obviously can't use v, ...
>>>
>>>>      pt->vcpu = v;
>>>> +
>>>> +    pt_vcpu_lock(pt->vcpu);
>>>>      if ( pt->on_list )
>>>>      {
>>>> -        list_del(&pt->list);
>>>>          list_add(&pt->list, &v->arch.hvm.tm_list);
>>>>          migrate_timer(&pt->timer, v->processor);
>>>>      }
>>>> +    pt_vcpu_unlock(pt->vcpu);
>>> ... these two again could (and imo should), and ...
>>>
>>>>      write_unlock(&pt->vcpu->domain->arch.hvm.pl_time->pt_migrate);
>>> ... really this and its counterpart better would do so, too (albeit
>>> perhaps in a separate patch).
>>
>> Are you suggesting to replace pt->vcpu with v here?
> Yes.
>
>> They are different at lock and unlock points (although they obviously point 
>> to the same domain).
> Indeed, but all we care about is - as you say - the domain.


Hmm.. I think then it's better to stash domain (or, better, pl_time) into a 
local variable. Otherwise starting with different pointers in lock and unlock 
paths (even though they eventually lead to the same lock) makes me a bit 
uncomfortable.


Secondly, do you want this and the check for pt->vcpu == v in pt_adjust_vcpu() 
be done in two separate patches or can they go into a single one?


-boris




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.