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 75BFAAC1054 for ; Sun, 25 Feb 2024 13:17:49 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=hI1HtK+ncx6NSD8+nqj3WqFektd8dUY80WA5dbY5up8=; 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=1708867068; v=1; b=rerpMbjZ3uItIVTKQ709f09392nieJrwoEYQ6Sgx6MHhnRQN8mBpebrr+Qo29GJlv4KWF4vB ip3oUCAWcaEWi6Suu0ksL1evAB1niQrqdB1b1OACTR+PL3ZHYRAwr4aLR0FNKv8fnmJwqO6fYEd yw+OhcYL7hbcvERM0NX+5YeA= X-Received: by 127.0.0.2 with SMTP id XUfWYY7687511xtdmlQ6pGEk; Sun, 25 Feb 2024 05:17:48 -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.web10.38561.1708867067602293779 for ; Sun, 25 Feb 2024 05:17:47 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-YKm_wTXIP2KwtuZkv4vlyQ-1; Sun, 25 Feb 2024 08:17:41 -0500 X-MC-Unique: YKm_wTXIP2KwtuZkv4vlyQ-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 59CA985A58C; Sun, 25 Feb 2024 13:17:41 +0000 (UTC) X-Received: from [10.39.192.57] (unknown [10.39.192.57]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 258834024860; Sun, 25 Feb 2024 13:17:39 +0000 (UTC) Message-ID: <4acf6d46-bd3b-cc38-eeeb-8d59db1cdb36@redhat.com> Date: Sun, 25 Feb 2024 14:17:38 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable To: "Ni, Ray" , Pedro Falcato , "devel@edk2.groups.io" Cc: "Zhou, Jianfeng" , "Kumar, Rahul R" , Gerd Hoffmann References: <20240221012513.27453-1-jianfeng.zhou@intel.com> <6bf89071-0514-cb97-f639-6bece14cc6d7@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 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: V4ZQA6hLpgGl3mCFkjnrxaudx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=rerpMbjZ; 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 2/22/24 11:23, Ni, Ray wrote: >>> I agree with the idea (I think it's a necessary change, or put >>> differently, an improvement, even though I may not be convinced that it >>> is a *sufficient* improvement; but let's not rehash all that here >>> again); however, I think the implementation is not the greatest. >>> >>> Volatile-qualifying the local variables does not seem useful for >>> anything. It's fine -- actually: it's beneficial -- if the compiler >>> optimizes accesses to those locals -- being on the stack -- as heavily >>> as it can. In other words, those parts of the patch look like a small >>> performance regression. >=20 > I did experiment using MSVC compiler with below code: > int main () { > int x; > x =3D 3; > return 0; > } >=20 > If building the above code in optimized mode, the disassembly does not co= ntain > any reference to local variable x. >=20 > But if I changed "int x" to "volatile int x", the compiler does not optim= ize out the > assignment of x. >=20 > So, it means the "volatile" matters even when it applies local variables= . Yes, but that's beside the point. It does not matter what kinds of accesses the compiler generates for the local variables, as those variables exist on the stack, and are not seen by anything else (certainly not by other processors). The accesses that matter are to the page tables, in dynamically allocated memory, so if anything, *those* accesses should be "volatile". Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115924): https://edk2.groups.io/g/devel/message/115924 Mute This Topic: https://groups.io/mt/104483610/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-