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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 54D03C433E0 for ; Thu, 28 May 2020 07:33:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 347E1208FE for ; Thu, 28 May 2020 07:33:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726433AbgE1Hds (ORCPT ); Thu, 28 May 2020 03:33:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbgE1Hds (ORCPT ); Thu, 28 May 2020 03:33:48 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AF91C05BD1E; Thu, 28 May 2020 00:33:48 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id B776F327; Thu, 28 May 2020 09:33:45 +0200 (CEST) Date: Thu, 28 May 2020 09:33:44 +0200 From: Joerg Roedel To: Bjorn Helgaas Cc: Zhangfei Gao , Bjorn Helgaas , Arnd Bergmann , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , jean-philippe , Greg Kroah-Hartman , Herbert Xu , kenneth-lee-2012@foxmail.com, Wangzhou , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Message-ID: <20200528073344.GO5221@8bytes.org> References: <1590493749-13823-1-git-send-email-zhangfei.gao@linaro.org> <20200527181842.GA256680@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200527181842.GA256680@bjorn-Precision-5520> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote: > Is this slowdown significant? We already iterate over every device > when applying PCI_FIXUP_FINAL quirks, so if we used the existing > PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be > adding two more iterations to the loop in pci_do_fixups() that tries > to match quirks against the current device. I doubt that would be a > measurable slowdown. I don't know how significant it is, but I remember people complaining about adding new PCI quirks because it takes too long for them to run them all. That was in the discussion about the quirk disabling ATS on AMD Stoney systems. So it probably depends on how many PCI devices are in the system whether it causes any measureable slowdown. Regards, Joerg