Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp558073pxh; Tue, 9 Nov 2021 15:12:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJzlDxUapTQ0IOIjj2D5ZE4CDGxvo7PJIJX3/v4PUd3eQycgNZRUiE1WgUX9AFGqY5E8uexR X-Received: by 2002:a02:ceb9:: with SMTP id z25mr8658738jaq.121.1636499572349; Tue, 09 Nov 2021 15:12:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636499572; cv=none; d=google.com; s=arc-20160816; b=RT/VV5GotPWi58L/OZ2IjV6bAwKk04BWr3dfi0szBGdnQ5/32j+3QZivjmivIBht1f FoBvq2BsletUUDioAVvpt8RCkwDc7dYy+yVK461vbg6eJgVGM9crFGHIxP7CiEsZojYA n6GSBu79+CRKerBypXAbWal4ysV2ZyIudu78hMfvpIVC+Oz1OhS0lk5Z4+rCPdI1hGwm 1ile/kR4k1CtvEIjAVIyRp2GRzrheZGQIle1hYB1nAUhsxa/yjQrmBAOS+h+IqtsEPPF 23Kr90dQOLZPsVxZ0qz44wOUksFIifqzEXBT0CExnVXki6nrDB8a4u7TnvDlhh7pRiNw uBaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=RG87Z0NXu15gcqa733+zWatvCEM7Ci40b2jWj4beiSY=; b=MMfi/ToTDR77fQItlc4nbvsSw8ePecW5vw6QC0FBDT22b1jmDQ3P5IO7Zep63Y8X+1 MQcdwIcHCRDePdpNJzCBJMMXieFgdTEDltp1a4S5UNG6coRedliR2f6NwE59juSwrDIl B3dIg+TEt4aESxKfmJkn+kWME8xEu6wszDGk3zIEMObe2ZhGrHKzn7dtMGfUo1d9yekh 78NgV/0PUwL6dI5ZwWxcvUNfHnDketmWtOmQW2P1bMz3hYVGBbDIWui0dtqd+S2ucsTb UlsTeXhegxsC8MnoXFKX3f3nF65vQHNov8vFULYYAjjJ/Ff5S1Nl8h7OtDIN6A9vCsYQ +ZlA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si52111152jat.11.2021.11.09.15.12.38; Tue, 09 Nov 2021 15:12:52 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244281AbhKIU2h (ORCPT + 99 others); Tue, 9 Nov 2021 15:28:37 -0500 Received: from mx3.molgen.mpg.de ([141.14.17.11]:33469 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S244263AbhKIU2h (ORCPT ); Tue, 9 Nov 2021 15:28:37 -0500 Received: from [192.168.0.2] (ip5f5aef56.dynamic.kabel-deutschland.de [95.90.239.86]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id AD90461EA1931; Tue, 9 Nov 2021 21:25:48 +0100 (CET) Message-ID: <4ec8db2c-295a-5060-1c0e-184ee072571e@molgen.mpg.de> Date: Tue, 9 Nov 2021 21:25:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: How to reduce PCI initialization from 5 s (1.5 s adding them to IOMMU groups) Content-Language: en-US To: =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= Cc: =?UTF-8?B?SsO2cmcgUsO2ZGVs?= , Suravee Suthikulpanit , Bjorn Helgaas , iommu@lists.linux-foundation.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, LKML , linux-pci@vger.kernel.org References: From: Paul Menzel In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Krzysztof, Thank you for your reply. Am 08.11.21 um 18:18 schrieb Krzysztof Wilczyński: >> On a PowerEdge T440/021KCD, BIOS 2.11.2 04/22/2021, Linux 5.10.70 takes >> almost five seconds to initialize PCI. According to the timestamps, 1.5 s >> are from assigning the PCI devices to the 142 IOMMU groups. > [...] >> Is there anything that could be done to reduce the time? > > I am curious - why is this a problem? Are you power-cycling your servers > so often to the point where the cumulative time spent in enumerating PCI > devices and adding them later to IOMMU groups is a problem? > > I am simply wondering why you decided to signal out the PCI enumeration as > slow in particular, especially given that a large server hardware tends to > have (most of the time, as per my experience) rather long initialisation > time either from being powered off or after being power cycled. I can take > a while before the actual operating system itself will start. It’s not a problem per se, and more a pet peeve of mine. Systems get faster and faster, and boottime slower and slower. On desktop systems, it’s much more important with firmware like coreboot taking less than one second to initialize the hardware and passing control to the payload/operating system. If we are lucky, we are going to have servers with FLOSS firmware. But, already now, using kexec to reboot a system, avoids the problems you pointed out on servers, and being able to reboot a system as quickly as possible, lowers the bar for people to reboot systems more often to, for example, so updates take effect. > We talked about this briefly with Bjorn, and there might be an option to > perhaps add some caching, as we suspect that the culprit here is doing PCI > configuration space read for each device, which can be slow on some > platforms. > > However, we would need to profile this to get some quantitative data to see > whether doing anything would even be worthwhile. It would definitely help > us understand better where the bottlenecks really are and of what magnitude. > > I personally don't have access to such a large hardware like the one you > have access to, thus I was wondering whether you would have some time, and > be willing, to profile this for us on the hardware you have. > > Let me know what do you think? Sounds good. I’d be willing to help. Note, that I won’t have time before Wednesday next week though. Kind regards, Paul