From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68D26C0015E for ; Wed, 9 Aug 2023 13:55:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229882AbjHINzn (ORCPT ); Wed, 9 Aug 2023 09:55:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231719AbjHINzk (ORCPT ); Wed, 9 Aug 2023 09:55:40 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 748A72109; Wed, 9 Aug 2023 06:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691589339; x=1723125339; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=gJzCp6ekx7CCevIM8uCATPGn/y4r8KOXNfeq4gNJ+QM=; b=Qg0+2Nep+LaeHsWEXoTUyECVQGp/Eyy1eQLr7qzNRBwX4iRVUngxLudL ICBnlAlAVPMuXrp0aBxFR8JAntGf5xxTJ9rZObs5ogZyl5hj/qNVZt+CR 90/H6M781soOAnKJHO4aindbjK1W6qm2daOEovl75Dhx48AB+9Lp739QB 0x4HFsFVLiROi3ieB3fqMqN/lnVP0w2J6LCGqHCNF5THGxyz6sEiRz3N0 Low51pM6/sFwSJSBFEEkNgnCsv3CmTfwC8hE2bzvxOACmoFu2rrIbzHoG x6imQVQingK30rZRBcy1NQPa330R16r+EfZ7Oj1BfPoGz7u8FCiNnsTCQ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="370029111" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="370029111" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="845966693" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="845966693" Received: from cvogler-mobl1.ger.corp.intel.com ([10.252.40.229]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:23 -0700 Date: Wed, 9 Aug 2023 16:55:20 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Sui Jingfeng cc: Bjorn Helgaas , Dave Airlie , Daniel Vetter , linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org, LKML , Sui Jingfeng Subject: Re: [PATCH v2 05/11] PCI/VGA: Move the new_state assignment out of the loop In-Reply-To: <20230808223412.1743176-6-sui.jingfeng@linux.dev> Message-ID: References: <20230808223412.1743176-1-sui.jingfeng@linux.dev> <20230808223412.1743176-6-sui.jingfeng@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, 9 Aug 2023, Sui Jingfeng wrote: > From: Sui Jingfeng > > In the vga_arbiter_notify_clients() function, the value of the 'new_state' > variable will be 'false' on systems that have more than one VGA device. > The value will be 'true' if there is only one VGA device or no VGA device > at all. Hence, its value is not relevant to the iteration of the loop. > > So move the assignment clause out of the loop. For a system with multiple > video cards, this patch saves unnecessary assignment. > > Signed-off-by: Sui Jingfeng > --- > drivers/pci/vgaarb.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c > index dc10a262fb5e..6883067a802a 100644 > --- a/drivers/pci/vgaarb.c > +++ b/drivers/pci/vgaarb.c > @@ -1468,22 +1468,20 @@ static void vga_arbiter_notify_clients(void) > { > struct vga_device *vgadev; > unsigned long flags; > - uint32_t new_decodes; > - bool new_state; > + bool state; > > if (!vga_arbiter_used) > return; > > + state = (vga_count > 1) ? false : true; > + Is it safe to move this outside of the lock? This would be enough (no need for ?: construct): state = vga_count <= 1; Or if you want to keep it as > 1: state = !(vga_count > 1); > spin_lock_irqsave(&vga_lock, flags); > list_for_each_entry(vgadev, &vga_list, list) { > - if (vga_count > 1) > - new_state = false; > - else > - new_state = true; > if (vgadev->set_decode) { > - new_decodes = vgadev->set_decode(vgadev->pdev, > - new_state); > - vga_update_device_decodes(vgadev, new_decodes); > + unsigned int decodes; > + > + decodes = vgadev->set_decode(vgadev->pdev, state); > + vga_update_device_decodes(vgadev, decodes); > } > } > spin_unlock_irqrestore(&vga_lock, flags); > -- i. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 232B9C001B0 for ; Thu, 10 Aug 2023 07:25:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3E4DB10E4CF; Thu, 10 Aug 2023 07:25:19 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0221410E444 for ; Wed, 9 Aug 2023 13:55:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691589340; x=1723125340; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=gJzCp6ekx7CCevIM8uCATPGn/y4r8KOXNfeq4gNJ+QM=; b=WHW0oUZNQA8ySOiq9/RnXeq6OB9FXneGI9GGNZnXIlT7DGsInqTF1ftT hOZxGTsfXjQkSNXFT9VpcbE+1VIBdOJZ/RwRXQi8lAdt62k4r8R6Zu0NV UjMof+5kX+59i18YrAfAwrP1n86uFZv5vryUadhev9lh2MGV0npkZfDT+ gy38nV1qw/AYBUzW67uHi4wzgifNl3qve8FyaE7aigWGW+ROI2dNmXOgm 7NLhdZqxNoQm0HEUvypqaYSdozDjw/+HTxGn9cnZW+lolDxU/RRrEdS3F /eJWiXOHsPXw3RPkaocz3MtYtp4x+cy6FRBI+OoTDKtPIrGekYsTRbBcn Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="370029114" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="370029114" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="845966693" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="845966693" Received: from cvogler-mobl1.ger.corp.intel.com ([10.252.40.229]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 06:55:23 -0700 Date: Wed, 9 Aug 2023 16:55:20 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Sui Jingfeng Subject: Re: [PATCH v2 05/11] PCI/VGA: Move the new_state assignment out of the loop In-Reply-To: <20230808223412.1743176-6-sui.jingfeng@linux.dev> Message-ID: References: <20230808223412.1743176-1-sui.jingfeng@linux.dev> <20230808223412.1743176-6-sui.jingfeng@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 10 Aug 2023 07:25:03 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sui Jingfeng , linux-pci@vger.kernel.org, LKML , dri-devel@lists.freedesktop.org, Bjorn Helgaas , Dave Airlie Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 9 Aug 2023, Sui Jingfeng wrote: > From: Sui Jingfeng > > In the vga_arbiter_notify_clients() function, the value of the 'new_state' > variable will be 'false' on systems that have more than one VGA device. > The value will be 'true' if there is only one VGA device or no VGA device > at all. Hence, its value is not relevant to the iteration of the loop. > > So move the assignment clause out of the loop. For a system with multiple > video cards, this patch saves unnecessary assignment. > > Signed-off-by: Sui Jingfeng > --- > drivers/pci/vgaarb.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c > index dc10a262fb5e..6883067a802a 100644 > --- a/drivers/pci/vgaarb.c > +++ b/drivers/pci/vgaarb.c > @@ -1468,22 +1468,20 @@ static void vga_arbiter_notify_clients(void) > { > struct vga_device *vgadev; > unsigned long flags; > - uint32_t new_decodes; > - bool new_state; > + bool state; > > if (!vga_arbiter_used) > return; > > + state = (vga_count > 1) ? false : true; > + Is it safe to move this outside of the lock? This would be enough (no need for ?: construct): state = vga_count <= 1; Or if you want to keep it as > 1: state = !(vga_count > 1); > spin_lock_irqsave(&vga_lock, flags); > list_for_each_entry(vgadev, &vga_list, list) { > - if (vga_count > 1) > - new_state = false; > - else > - new_state = true; > if (vgadev->set_decode) { > - new_decodes = vgadev->set_decode(vgadev->pdev, > - new_state); > - vga_update_device_decodes(vgadev, new_decodes); > + unsigned int decodes; > + > + decodes = vgadev->set_decode(vgadev->pdev, state); > + vga_update_device_decodes(vgadev, decodes); > } > } > spin_unlock_irqrestore(&vga_lock, flags); > -- i.