[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
- To: Julien Grall <julien@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 11 Apr 2022 12:45:49 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JQIt2KH/LPlOVO/K1JQ2W6WZuAzLqxdu/AirvMUWfP0=; b=muUUJG/ih9WNTjzx8k5/fn/CgfZ1J5Bv9jwJ9+E5UTcILr3Ftbn4bnQPVN7s6onamxoHsWSIeAnc4HKA8wzA7Sel5wQSw64fXR+IwQZrENlEXfGXHicecGc3JrvSRU5UatzQuSdfGeSRT8CAs4zdMiM+fGFCN9ekf7oT5C06/O8sKEDL5/rHnBEUnqsf61tbdiOhjihZItbdHwSS/51/yUXsQxBb7DAwlQOTBZf3doueHkdg8s2O1n0jDXErTeT2Du8nm6Sb6TTFUhnzV3xkTOIxkC27c3vRfzP+hhdfulKNxikr3hBQx4iUliRG7bjFaclR8lYx7QQzINNqGtiXdA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mc5GdXunLuFx407oxI/gB1jy1g9YMumaWhx3YnmdKvS4E+3UBwPT0dRYc8C0xhhLNcdfbbqElLLrfC5xeoJdwqt4xBHHO+T20oPEBwupWvvBQgYmuqA/lPn62th6a1NRmj/FDExW0j5diZM7rwrwtkKAaP87XRFbmf98FmPFptK3LX0eOCbb496vrqccIcs6r/qVOyFTdsU0psxSZKE3Gr1hvwhNKBv6+TjGoV4wtDNTIe7ZkAczrh1IUfNOO1pqIFNIpVEp0Tr/ND2tYVCnBiu9YNeS/Csf0yVxXPWyjD3R0JhLv1yeIc9DHESbD8embfRvTAMFuQlvsx717byxcg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 11 Apr 2022 10:45:58 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11.04.2022 12:25, Julien Grall wrote:
> On 11/04/2022 07:13, Jan Beulich wrote:
>>>>>> --- a/xen/common/event_channel.c
>>>>>> +++ b/xen/common/event_channel.c
>>>>>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
>>>>>> unsigned int port;
>>>>>> struct evtchn *chn;
>>>>>>
>>>>>> + /*
>>>>>> + * The work done below is an attempt to keep pIRQ-s on the pCPU-s
>>>>>> that the
>>>>>> + * vCPU-s they're to be delivered to run on. In order to limit lock
>>>>>> + * contention, check for an empty list prior to acquiring the lock.
>>>>>> In the
>>>>>> + * worst case a pIRQ just bound to this vCPU will be delivered
>>>>>> elsewhere
>>>>>> + * until the vCPU is migrated (again) to another pCPU.
>>>>>> + */
>>>>>
>>>>> AFAIU, the downside is another pCPU (and therefore vCPU) will get
>>>>> disturbed by the interrupt.
>>>>
>>>> But only rarely, i.e. in case a race would actually have occurred.
>>>
>>> Maybe I am too paranoid here. The other side of race is controlled by a
>>> domain. So wouldn't it be possible to increase how often the race is hit?
>>
>> Yes, of course - just to harm itself.
>
> Are you sure? Wouldn't this also harm the next vCPU running on the pCPU
> because it will get interrupted more often?
Possibly, sure. But we don't make any promises here. And recall that
this optimization as a whole has been put under question in the past.
If we'd drop it, we'd also impact various vCPU-s in not really
predictable ways.
Jan
|
