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 7FB64AC1279 for ; Fri, 12 Jan 2024 09:45:13 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=9bEz8aEqRTDWIDmeXVQs6zTCGViXd3ji6QnWyuEUAhg=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1705052712; v=1; b=fke4ge+DEeZeBhBfrbABT/75E/ZjNZ2iXmmoOvaCF8IfOlobuxF+R+1WG/iyz0MLME1S9tkP sXk1G6D3J4rH7Kty5FMBTAPhmr3Sv/ejPnf6bZaV7xQtwdy8K0yuwAZ9pflybxcD+X49FiYFWsH zEoFLMsIHNEmdI9Wi+43Pep8= X-Received: by 127.0.0.2 with SMTP id exLgYY7687511xwexUu1hIDC; Fri, 12 Jan 2024 01:45:12 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.3848.1705052711335715759 for ; Fri, 12 Jan 2024 01:45:11 -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-343-lajsVIVAO5WYb9G26HcwMQ-1; Fri, 12 Jan 2024 04:45:07 -0500 X-MC-Unique: lajsVIVAO5WYb9G26HcwMQ-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 C3F8338143BB; Fri, 12 Jan 2024 09:45:06 +0000 (UTC) X-Received: from [10.39.192.105] (unknown [10.39.192.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2B2E492BF0; Fri, 12 Jan 2024 09:45:05 +0000 (UTC) Message-ID: <8d745268-263c-c99a-67c6-fe0fb6cd4b8e@redhat.com> Date: Fri, 12 Jan 2024 10:45:04 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] Memory Attribute for depex section To: "Andrew (EFI) Fish" , edk2-devel-groups-io Cc: nhi@os.amperecomputing.com, "ardb+tianocore@kernel.org" References: <44ca139f-4d78-4322-b5b6-8e9788bb7486@os.amperecomputing.com> <2ad16043-754e-3bb9-3a4a-702d9a50bf63@redhat.com> <45b95719-f1fc-dbc6-a4cc-a022d691844c@redhat.com> From: "Laszlo Ersek" In-Reply-To: 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,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: cqB77ZTHyc0xdB3gVG6fCBuSx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=fke4ge+D; 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 On 1/12/24 03:44, Andrew (EFI) Fish wrote: > Sorry need some more time to digest this…. First thoughts. > > 1) The actual performance issue we hit was the explosion > of CoreValidateHandle() calls as the number of protocols got large for > some diags. The newer handles tended to be at the end of the list if I > remember correctly.  >   a) It looks like CoreValidateHandle() is the only > place  *gHandleList* was walked, as the handle info is crossed > referenced in the protocol database. So that is why we changed that. > 2) If the issue at hand is MM why not just drop the optimizations? Yes, that's the first (and easy) idea. But I guess it needs some measurements (no perf regression). It would be nice to know whether Intel (?) measured any serious perf gains when they originally implemented (in the 2000s?) the optimization. >   b) If we have so many MM protocols and handles that seems like its own > problem?  I would agree; however, IIRC, the depex evaluator for the MM drivers also searches the UEFI (DXE) protocol database, not just the MM protocol database. (Independently: I think that's a valid thing to do for *SMM* drivers, because the entry point functions of those drivers are permitted to use both SMM and DXE/UEFI protocols. But whether the same is valid for the *standalone* MM drivers -- that looks questionable. Standalone MM drivers should not depend on UEFI/DXE protocols ever, IIUC.) > 3) The issue is patching the grammar in place, why can’t we just make a > copy for the dispatcher grammer, and operate on the copy. Maybe via a > copy on 1st update strategy?  Yes, copying the depex to the heap, and patching it there, was Nhi's #1 fix proposal. I think that could be made work. But I'm not sure if the perf savings are worth the additional complexity. The heap allocation (where the writeable depex would exist) would have to be permanently associated with the loaded PE image -- because the dispatcher might need to reevaluate the depex across multiple rounds of dispatching. So that's a new field in some image-related structure, it also needs to be freed upon unload (?), what if the memory allocation fails during depex eval (just consider the depex to eval to FALSE?), etc. Doable, but hairy; not sure if the perf is worth that effort. Thanks! Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113704): https://edk2.groups.io/g/devel/message/113704 Mute This Topic: https://groups.io/mt/103594587/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-