From patchwork Wed Nov 25 11:16:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 11931223 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C92C1C56202 for ; Wed, 25 Nov 2020 11:17:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 61DE82075A for ; Wed, 25 Nov 2020 11:17:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FnWUVu3y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727327AbgKYLRM (ORCPT ); Wed, 25 Nov 2020 06:17:12 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:22693 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725616AbgKYLRM (ORCPT ); Wed, 25 Nov 2020 06:17:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606303030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=d6tPyIFWwC9FLM9lbcLTabTSHj2Cdv4CTmQuu8Xctvw=; b=FnWUVu3yi8CZ9wZDLnkj0qN4WnBMElWrZl4LPttS5e/sGV3Zl/4k6CEp2ALjcnblxkY+Zn iaOXzpS7/Ak+lDJf4zaipdMN/aIXibnh5yTfzcEbCH+FPNBYKhqKS7PuIxBjRRCKFToM4j VGkJFZ1eXafc58wODfbJAk8bHRY9Pro= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-183-QfIHT8QaNkSP_gbhcImWEw-1; Wed, 25 Nov 2020 06:17:06 -0500 X-MC-Unique: QfIHT8QaNkSP_gbhcImWEw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B793F1005D53; Wed, 25 Nov 2020 11:17:04 +0000 (UTC) Received: from thinkpad.redhat.com (ovpn-113-83.ams2.redhat.com [10.36.113.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7B2131002C11; Wed, 25 Nov 2020 11:16:58 +0000 (UTC) From: Laurent Vivier To: linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, Paul Mackerras , linux-pci@vger.kernel.org, Thomas Gleixner , Marc Zyngier , linuxppc-dev@lists.ozlabs.org, Benjamin Herrenschmidt , "Michael S . Tsirkin" , Greg Kurz , Christoph Hellwig , Michael Ellerman , Laurent Vivier Subject: [PATCH v2 0/2] powerpc/pseries: fix MSI/X IRQ affinity on pseries Date: Wed, 25 Nov 2020 12:16:55 +0100 Message-Id: <20201125111657.1141295-1-lvivier@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org With virtio, in multiqueue case, each queue IRQ is normally bound to a different CPU using the affinity mask. This works fine on x86_64 but totally ignored on pseries. This is not obvious at first look because irqbalance is doing some balancing to improve that. It appears that the "managed" flag set in the MSI entry is never copied to the system IRQ entry. This series passes the affinity mask from rtas_setup_msi_irqs() to irq_domain_alloc_descs() by adding an affinity parameter to irq_create_mapping(). The first patch adds the parameter (no functional change), the second patch passes the actual affinity mask to irq_create_mapping() in rtas_setup_msi_irqs(). For instance, with 32 CPUs VM and 32 queues virtio-scsi interface: ... -smp 32 -device virtio-scsi-pci,id=virtio_scsi_pci0,num_queues=32 for IRQ in $(grep virtio2-request /proc/interrupts |cut -d: -f1); do for file in /proc/irq/$IRQ/ ; do echo -n "IRQ: $(basename $file) CPU: " ; cat $file/smp_affinity_list done done Without the patch (and without irqbalanced) IRQ: 268 CPU: 0-31 IRQ: 269 CPU: 0-31 IRQ: 270 CPU: 0-31 IRQ: 271 CPU: 0-31 IRQ: 272 CPU: 0-31 IRQ: 273 CPU: 0-31 IRQ: 274 CPU: 0-31 IRQ: 275 CPU: 0-31 IRQ: 276 CPU: 0-31 IRQ: 277 CPU: 0-31 IRQ: 278 CPU: 0-31 IRQ: 279 CPU: 0-31 IRQ: 280 CPU: 0-31 IRQ: 281 CPU: 0-31 IRQ: 282 CPU: 0-31 IRQ: 283 CPU: 0-31 IRQ: 284 CPU: 0-31 IRQ: 285 CPU: 0-31 IRQ: 286 CPU: 0-31 IRQ: 287 CPU: 0-31 IRQ: 288 CPU: 0-31 IRQ: 289 CPU: 0-31 IRQ: 290 CPU: 0-31 IRQ: 291 CPU: 0-31 IRQ: 292 CPU: 0-31 IRQ: 293 CPU: 0-31 IRQ: 294 CPU: 0-31 IRQ: 295 CPU: 0-31 IRQ: 296 CPU: 0-31 IRQ: 297 CPU: 0-31 IRQ: 298 CPU: 0-31 IRQ: 299 CPU: 0-31 With the patch: IRQ: 265 CPU: 0 IRQ: 266 CPU: 1 IRQ: 267 CPU: 2 IRQ: 268 CPU: 3 IRQ: 269 CPU: 4 IRQ: 270 CPU: 5 IRQ: 271 CPU: 6 IRQ: 272 CPU: 7 IRQ: 273 CPU: 8 IRQ: 274 CPU: 9 IRQ: 275 CPU: 10 IRQ: 276 CPU: 11 IRQ: 277 CPU: 12 IRQ: 278 CPU: 13 IRQ: 279 CPU: 14 IRQ: 280 CPU: 15 IRQ: 281 CPU: 16 IRQ: 282 CPU: 17 IRQ: 283 CPU: 18 IRQ: 284 CPU: 19 IRQ: 285 CPU: 20 IRQ: 286 CPU: 21 IRQ: 287 CPU: 22 IRQ: 288 CPU: 23 IRQ: 289 CPU: 24 IRQ: 290 CPU: 25 IRQ: 291 CPU: 26 IRQ: 292 CPU: 27 IRQ: 293 CPU: 28 IRQ: 294 CPU: 29 IRQ: 295 CPU: 30 IRQ: 299 CPU: 31 This matches what we have on an x86_64 system. v2: add a wrapper around original irq_create_mapping() with the affinity parameter. Update comments Laurent Vivier (2): genirq: add an irq_create_mapping_affinity() function powerpc/pseries: pass MSI affinity to irq_create_mapping() arch/powerpc/platforms/pseries/msi.c | 3 ++- include/linux/irqdomain.h | 12 ++++++++++-- kernel/irq/irqdomain.c | 13 ++++++++----- 3 files changed, 20 insertions(+), 8 deletions(-)