Re: x86/mm: Limit 2/4M size calculation to x86_32

[Stefan Bader]

On 25.07.2012 15:40, Avi Kivity wrote:
> On 07/25/2012 04:24 PM, Stefan Bader wrote:
>>>> ...
>>>> ifdef CONFIG_X86_32
>>>>         /*
>>>>          * Don't use a large page for the first 2/4MB of memory
>>>>          * because there are often fixed size MTRRs in there
>>>>          * and overlapping MTRRs into large pages can cause
>>>>          * slowdowns.
>>>>          */
>>>>
>>>
>>> That's equally true for X86_64.
>>>
>>> Best would be to merge the MTRRs into PAT, but that might not work for SMM.
>>>
>>>
>> Ok, true. Not sure why this was restricted to 32bit when reconsidering. Except
>> if in 64bit it was assumed (or asserted) that the regions are aligned to 2M...
>> But maybe this can be answered by someone knowing the details. I would not mind
>> either way (have the first range with 4K pages in all cases or fixing the
>> additional PTE allocation). Just as it is now it is inconsistent.
> 
> Sometimes CONFIG_X86_32 is used as an alias for "machines so old they
> don't support x86_64".  As a 32-bit kernel can be run on a machine that
> does support x86_64, it should be replaced by a runtime test for
> X86_FEATURE_LM, until a more accurate test can be found.
> 

So basically the first range being 4k exist because MTRRs might define ranges
there and those are always aligned to 4k but not necessarily to the bigger pages
used. Reading through the Intel and AMD docs indicates various levels of badness
when this is not the case. Though afaict MTRRs are not tied to long mode capable
CPUs. For example Atom is 32bit only (the earlier ones at least) and uses MTRRs.
So testing for LM would miss those.
Would it not be better to unconditionally have the first 2/4M as 4k pages? At
least as long as there is no check for the alignment of the MTRR ranges. Or
thinking of it, the runtime test should look for X86_FEATURE_MTRR, shouldn't it?

Attachment: signature.asc
Description: OpenPGP digital signature