public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Ni, Ray" <ray.ni@intel.com>,
	Pedro Falcato <pedro.falcato@gmail.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Zhou, Jianfeng" <jianfeng.zhou@intel.com>,
	"Kumar, Rahul R" <rahul.r.kumar@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable
Date: Sun, 25 Feb 2024 14:17:38 +0100	[thread overview]
Message-ID: <4acf6d46-bd3b-cc38-eeeb-8d59db1cdb36@redhat.com> (raw)
In-Reply-To: <DM4PR11MB8226B256C218198B343CEFB18C562@DM4PR11MB8226.namprd11.prod.outlook.com>

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.
> 
> I did experiment using MSVC compiler with below code:
>   int main () {
>     int x;
>     x = 3;
>     return 0;
>   }
> 
> If building the above code in optimized mode, the disassembly does not contain
> any reference to local variable x.
> 
> But if I changed "int x" to "volatile int x", the compiler does not optimize out the
> assignment of x.
> 
> 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



-=-=-=-=-=-=-=-=-=-=-=-
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]
-=-=-=-=-=-=-=-=-=-=-=-



      reply	other threads:[~2024-02-25 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  1:25 [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable Zhou Jianfeng
2024-02-21  5:47 ` Ni, Ray
2024-02-21 20:36 ` Laszlo Ersek
2024-02-21 21:44   ` Pedro Falcato
2024-02-22  3:01     ` Zhou, Jianfeng
2024-02-22 10:23     ` Ni, Ray
2024-02-25 13:17       ` Laszlo Ersek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4acf6d46-bd3b-cc38-eeeb-8d59db1cdb36@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox