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

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

On 25.07.2012 14:32, Avi Kivity wrote:
> On 07/25/2012 02:14 PM, Stefan Bader wrote:
>> On 25.07.2012 12:44, Avi Kivity wrote:
>>> On 07/24/2012 06:52 PM, Cong Wang wrote:
>>>
>>>>> From 6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001
>>>>> From: Stefan Bader <stefan.bader@canonical.com>
>>>>> Date: Fri, 13 Jul 2012 15:16:33 +0200
>>>>> Subject: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32
>>>>>
>>>>> commit 722bc6b (x86/mm: Fix the size calculation of mapping tables)
>>>>> did modify the extra space calculation for mapping tables in order
>>>>> to make up for the first 2/4M memory range using 4K pages.
>>>>> However this setup is only used when compiling for 32bit. On 64bit
>>>>> there is only the trailing area of 4K pages (which is already added).
>>>>>
>>>>> The code was already adapted once for things went wrong on a 8TB
>>>>> machine (bd2753b x86/mm: Only add extra pages count for the first memory
>>>>> range during pre-allocation early page table space), but it looks a bit
>>>>> like it currently would overdo things for 64bit.
>>>>> I only noticed while bisecting for the reason I could not make a crash
>>>>> kernel boot (which ended up on this patch).
>>>>>
>>>>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>>>>> Cc: WANG Cong <xiyou.wangcong@gmail.com>
>>>>> Cc: Yinghai Lu <yinghai@kernel.org>
>>>>> Cc: Tejun Heo <tj@kernel.org>
>>>>
>>>> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
>>>>
>>>> Sorry for that I was not aware of x86_64 is different with x86 in the
>>>> first 2/4M.
>>>
>>> Why would there be a difference?
>>>
>>> Shouldn't the IO space at 0xa0000-0x100000 be mapped with uncacheable
>>> attributes (or WC for VGA)?  If it's done later, it can be done later
>>> for both.
>>>
>> arch/x86/mm/init.c
>>
>> unsigned long __init_refok init_memory_mapping(...
>> ...
>> 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]