Messages in this thread | | | Date | Wed, 5 Jan 2022 12:46:11 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH 19/26] x86/tdx: Make pages shared in ioremap() |
| |
On Tue, Jan 04, 2022 at 05:38:25PM -0800, Dave Hansen wrote: > On 1/4/22 4:57 PM, Kirill A. Shutemov wrote: > >> My read of STRICT_MM_TYPECHECKS was that "typedef unsigned long > >> pgprot_t" produces better code, but "typedef struct { unsigned long > >> pgprot; } pgprot_t;" produces better type checking. > > Apart from pgprot_t, __pgprot() and pgrot_val() helpers are defined > > differently depending on STRICT_MM_TYPECHECKS. > > > >> I just compiled these patches on sparc with no issues. > > Hm. I can't see how > > > > #define pgprot_val(x) (x) > > > > can work to access value for the pgprot_t defined as a struct. > > Oh, I must just be compiling with the strict type checks on all the > time. I do really wonder if these are useful these days or if the hacks > were for ancient compilers. > > In any case, this would be pretty easy to fix by just removing the > !STRICT_MM_TYPECHECKS pgprot_val() and defning the STRICT_MM_TYPECHECKS > universally.
There's comment in 32-bit Sparc as a reason for STRICT_MM_TYPECHECKS not to be used:
/* passing structs on the Sparc slow us down tremendously... */
The comment came from before git times, so I don't know if it still has a merit or newer compilers can deal with it better.
bloat-o-meter shows not trivial difference:
Total: Before=5342261, After=5344025, chg +0.03%
but I'm not sure if it translates into performance loss.
David, does the comment still relevant?
-- Kirill A. Shutemov
| |