[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 8 Apr 2022 09:16:02 +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=+pDejtzsEifzIy04C1ku0J2v8gAR4+ceFtzM7W/JNZU=; b=Vs3FwxauyNgRpBCHbmLWuQ93ue+QSV/j0inIbv9DjGphilUivhkmiXXt9+skdQgy+ctL+GSTkD7Udn+339ylbP+xMn1kMH/TJHdIj8Pjg25twyZjTjAY/ODEBO7nYOT+p9Lr7g5U94HvDlsjrZtjBqjty5owRwPXw1P6WZ/Bb01vdBEriBK4GrAj8/mH/ZMm6t2VABml980sW49fzUNVcU2hkCgO/4Xihi3uk4LsqsVgveVfX3NWYTuc05oDUhL+SRm9dIGEDCWGJI4UztMuarN/28MqkiXWXyobpCgmFwCCblZDLmGaUqS0/bx1VOK2A9LUfC1vNkaCE2fRTRAtqg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TT/bTL6Vx0RmcSyIdDdW0lSFT67aPCF/va7VY4xFHPT+2fI30MdBIzW+T54G7QaEFhVzpvZmRgmQLNSH+CnQuh1FxxLoLoAuVwYT5DDEED9ngjj642OPs/005zeF8h+/fFBL0AeZuUOFnszK5F/7QZbK42M+pG8iQpnCEu6H3cMdpwFPNDG45hlJaViBXk4qlYoKQfOvoRagxrqRYJH5Jl6rzYji5YhVis1J9CrESmP1juf98T5AIufMXYGnWvzNt+qcEAmqK8ox+ax0FpZGsfAWf+/c7MKnZhS5hDUQQ6nyoi0AOv1D3HnQEpm3jOBgkb45mF3VF/E2JlMUbOSjoA==
- 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>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>
- Delivery-date: Fri, 08 Apr 2022 07:16:13 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
See the code comment. The higher the rate of vCPU-s migrating across
pCPU-s, the less useful this attempted optimization actually is. With
credit2 the migration rate looks to be unduly high even on mostly idle
systems, and hence on large systems lock contention here isn't very
difficult to observe.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
--- 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.
+ */
+ if ( !v->pirq_evtchn_head )
+ return;
+
spin_lock(&d->event_lock);
for ( port = v->pirq_evtchn_head; port; port = chn->u.pirq.next_port )
{
|
