Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp295982pxu; Wed, 14 Oct 2020 01:16:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygD8oftmsXHYGUr7p0b60KN2KLqbhO2euNzqgWHTT9ZjnWhdod1/JDi/vku6uDjeiX4ozE X-Received: by 2002:a17:906:bc50:: with SMTP id s16mr3933484ejv.275.1602663364756; Wed, 14 Oct 2020 01:16:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602663364; cv=none; d=google.com; s=arc-20160816; b=R1cubBlEp5dmuVuGg7hp9/ELPpqQxQDb6nf30B/w9IG7p96yDHHPxym8nZ7me868mF e8kiNh8fklyDaoTFkHRAWWb6/v9nQ8M01V82dsIukCYwUAJI7jLjpaJWUDKpQ6Sp8ZNn J5jrDYcOVFNZVMHd/5hthTS10qL5uqJf0XtVN6rfp/GpyNcDxEDTXfqQdiDOaOpNNHC9 iOrK/VNoUbscc0MRmYxhOFf9AkDu0jZI3lX063BvVgffDQRiLysuZdIv+H3Xl6nftoIF ORH6SDKjfQ6PjUM/oxhBbCZ2NKOqFcT7XkacalD4/1cd2XrCcJo0vtWqyynM+ZM1a6ON ypMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=Kfmf77NswTlE78r/Rx1pWvh7Mse6dTExyPAMh1Ho+z8=; b=g0Kq/0eMyAwtKaaIqWu5Atz0YDBiKULG9EZ7fJL6+wUT2AVY9zaC8+C5h0P2nH2aBB isOW8NzTJnhVG1iUvlbIUgh8hiSB3t8ktbkxkiNBSqgvUrOf54J52MNMuzPIqq4M5hXT 52k72MnFwNLrvDQF2oFG9fV5fdHSJaIIfM/93joAjh1Prmre9tkUUF3uSWjRDojtn0fD +KqRnOGd/5AEYGPSrskKgEYDUik4MMk9LN++XAhhSWGm94DyPOUQmSp/3JL0gURx/0+p tBsyxSPpe32VdMbxax5dJLKmQo4ceXJntUYNLH/WHDmx+wG7BRuk5lrMmxTYmUi4If+j FYtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=X5+qbXXc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b13si1676555edf.523.2020.10.14.01.15.42; Wed, 14 Oct 2020 01:16:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=X5+qbXXc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730732AbgJNAud (ORCPT + 99 others); Tue, 13 Oct 2020 20:50:33 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:21913 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730666AbgJNAud (ORCPT ); Tue, 13 Oct 2020 20:50:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602636630; 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: in-reply-to:in-reply-to:references:references; bh=Kfmf77NswTlE78r/Rx1pWvh7Mse6dTExyPAMh1Ho+z8=; b=X5+qbXXciTbvZnGhjbP6GTuPQxL9fHBgdhj7LgD/4fybkHp9pf7piMRtuXeNlZxOzse01B qLkCX8RPy6L7exezkkN89buLAdu0sR8ZQMW1snLbWZ4AWkHXcQnPcI3REpBfm8Vr47AX7t iFrQYfW5hk4lJNmpoMHNzzD7p9BGHr8= 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-542-0Yys-8R6Pzu35lIbEX78lQ-1; Tue, 13 Oct 2020 20:50:29 -0400 X-MC-Unique: 0Yys-8R6Pzu35lIbEX78lQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AD93F1800D42; Wed, 14 Oct 2020 00:50:27 +0000 (UTC) Received: from x1.home (ovpn-113-35.phx2.redhat.com [10.3.113.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0774155767; Wed, 14 Oct 2020 00:50:23 +0000 (UTC) Date: Tue, 13 Oct 2020 18:50:23 -0600 From: Alex Williamson To: "Song Bao Hua (Barry Song)" Cc: "tiantao (H)" , "eric.auger@redhat.com" , "cohuck@redhat.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linuxarm Subject: Re: [PATCH] vfio/platform: Replace spin_lock_irqsave by spin_lock in hard IRQ Message-ID: <20201013185023.455a6ca9@x1.home> In-Reply-To: References: <1602554458-26927-1-git-send-email-tiantao6@hisilicon.com> <20201013153229.7fe74e65@w520.home> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Oct 2020 00:15:13 +0000 "Song Bao Hua (Barry Song)" wrote: > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: Wednesday, October 14, 2020 10:32 AM > > To: tiantao (H) > > Cc: eric.auger@redhat.com; cohuck@redhat.com; kvm@vger.kernel.org; > > linux-kernel@vger.kernel.org; Song Bao Hua (Barry Song) > > ; Linuxarm > > Subject: Re: [PATCH] vfio/platform: Replace spin_lock_irqsave by spin_lock in > > hard IRQ > > > > On Tue, 13 Oct 2020 10:00:58 +0800 > > Tian Tao wrote: > > > > > It is redundant to do irqsave and irqrestore in hardIRQ context. > > > > But this function is also called from non-IRQ context. Thanks, > > It seems you mean > vfio_platform_set_irqs_ioctl() -> > vfio_platform_set_irq_trigger -> > handler() ? Yes. > so, will it be better to move the irqsave out of the vfio_automasked_irq_handler() > and put it to where the function is called in non-IRQ context? > > I mean: > > irqhandler() > { > spin_lock() //without irqsave > spin_unlock() > } > > Non-irq context which is calling this handler: > irqsave(); > irqhandler(); > irqrestore(); > > Anyway, if it is called in IRQ context, it is redundant to do irqsave. What's the advantage? You're saying it's redundant, is it also wrong? If it's not wrong and only redundant, what's the tangible latency difference in maintaining a separate IRQ context handler without the irqsave/restore? Thanks, Alex > > > Signed-off-by: Tian Tao > > > --- > > > drivers/vfio/platform/vfio_platform_irq.c | 5 ++--- > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/vfio/platform/vfio_platform_irq.c > > b/drivers/vfio/platform/vfio_platform_irq.c > > > index c5b09ec..24fd6c5 100644 > > > --- a/drivers/vfio/platform/vfio_platform_irq.c > > > +++ b/drivers/vfio/platform/vfio_platform_irq.c > > > @@ -139,10 +139,9 @@ static int vfio_platform_set_irq_unmask(struct > > vfio_platform_device *vdev, > > > static irqreturn_t vfio_automasked_irq_handler(int irq, void *dev_id) > > > { > > > struct vfio_platform_irq *irq_ctx = dev_id; > > > - unsigned long flags; > > > int ret = IRQ_NONE; > > > > > > - spin_lock_irqsave(&irq_ctx->lock, flags); > > > + spin_lock(&irq_ctx->lock); > > > > > > if (!irq_ctx->masked) { > > > ret = IRQ_HANDLED; > > > @@ -152,7 +151,7 @@ static irqreturn_t vfio_automasked_irq_handler(int > > irq, void *dev_id) > > > irq_ctx->masked = true; > > > } > > > > > > - spin_unlock_irqrestore(&irq_ctx->lock, flags); > > > + spin_unlock(&irq_ctx->lock); > > > > > > if (ret == IRQ_HANDLED) > > > eventfd_signal(irq_ctx->trigger, 1); > > Thanks > Barry >