From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 571D87803CD for ; Mon, 19 Feb 2024 11:37:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=LaIapxHGQ+dIc5BlwPBDuU93WlITkaq0feGvu6cTPXQ=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1708342666; v=1; b=HzuJRBGiUqcDB3kJp/uo0gfKWg8HG3WK/yVNZLvv9l34yJYNOd+YtQ9VgRkSQ0mTqp3zGjpk uL3O5U3EPqmxI29psTF9XqHCnziuDZuKxPI2KLCERe4hNxldO927ojzYE2xjlriryg33mHFU6yT /6h9ZyL7dKNk36bzGMIw4HLc= X-Received: by 127.0.0.2 with SMTP id 68M9YY7687511xY3EgRtdPUP; Mon, 19 Feb 2024 03:37:46 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.39567.1708342666242282363 for ; Mon, 19 Feb 2024 03:37:46 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-Sh7NtSWhMZykJeHDC7VQ_g-1; Mon, 19 Feb 2024 06:37:42 -0500 X-MC-Unique: Sh7NtSWhMZykJeHDC7VQ_g-1 X-Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1E5C0299E742; Mon, 19 Feb 2024 11:37:42 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.193.175]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC980492BE2; Mon, 19 Feb 2024 11:37:41 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A7D811800DCF; Mon, 19 Feb 2024 12:37:40 +0100 (CET) Date: Mon, 19 Feb 2024 12:37:40 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Oliver Steffen , Ray Ni , Rahul Kumar Subject: Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber() Message-ID: <6sj7g5q4izxbcpyysed4shml4ru262qezr46qj7iykh7brqlgw@jj4wy2vngh2d> References: <20240215093149.251319-1-kraxel@redhat.com> <20240215093149.251319-3-kraxel@redhat.com> <392712ae-99d9-eced-2b9c-ce87403be4ce@redhat.com> MIME-Version: 1.0 In-Reply-To: <392712ae-99d9-eced-2b9c-ce87403be4ce@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: VFKckEnN0LhQhYFyKkPdXs4Fx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=HzuJRBGi; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, > (I'm missing the larger picture here -- is this related to the problem > -- too many CPUs to fit their infos into a single HOB -- that Pawel > worked on for a while? Different HOB, but similar underlying problem. At least the HOB structure already has the fields needed to allow splitting the information into multiple HOBs, even though the current code doesn't actually do that (which is fixed by this series). > The outer loop is suboptimal, IMO, to just open-coding another HOB scan > -- this approach looks quadratic, even though it could be linear. More > or less, as proposed, we call GetMpHandOffHob() for each MP_HAND_OFF > HOB, which will scan n/2 HOBs on average. (Even if the GUID HOB list is > sorted by ProcessorIndex, we'll scan 1 + 2 + 3 +... HOBs.) But if we > open-coded GetFirstGuidHob() and GetNextGuidHob() here, then a single > scan would suffice. Ray raised performance concerns too. Does HobLib provides any ordering guarantees? Specifically in case the HOBs are returned in the same order they are created (which implies they are sorted by ProcessorIndex because patch #5 creates them in that order) this can certainly be optimized. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115593): https://edk2.groups.io/g/devel/message/115593 Mute This Topic: https://groups.io/mt/104369845/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-