Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

H. Peter Anvin
2013-08-23T13:11:04Z

What is the point of 1G+MTRR? If there are caching differences the TLB will fracture the pages anyway.

Tejun Heo <tj@kernel.org> wrote:
>Hello, Toshi.
>
>On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
>> I am relatively new to Linux, so I am not a good person to elaborate
>> this. From my experience on other OS, huge pages helped for the
>kernel,
>> but did not necessarily help user applications. It depended on
>> applications, which were not niche cases. But Linux may be
>different,
>> so I asked since you seemed confident. I'd appreciate if you can
>point
>> us some data that endorses your statement.
>
>We are talking about the kernel linear mapping which is created during
>early boot, so if it's available and useable there's no reason not to
>use it. Exceptions would be earlier processors which didn't do 1G
>mappings or e820 maps with a lot of holes. For CPUs used in NUMA
>configurations, the former has been history for a bit now. Can't be
>sure about the latter but it'd be surprising for that to affect large
>amount of memory in the systems that are of interest here. Ooh, that
>reminds me that we probably wanna go back to 1G + MTRR mapping under
>4G. We're currently creating a lot of mapping holes.
>
>> My worry is that the code is unlikely tested with the special logic
>when
>> someone makes code changes to the page tables. Such code can easily
>be
>> broken in future.
>
>Well, I wouldn't consider flipping the direction of allocation to be
>particularly difficult to get right especially when compared to
>bringing in ACPI tables into the mix.
>
>> To answer your other question/email, I believe Tang's next step is to
>> support local page tables. This is why we think pursing SRAT earlier
>is
>> the right direction.
>
>Given 1G mappings, is that even a worthwhile effort? I'm getting even
>more more skeptical.
>
>Thanks.

--
Sent from my mobile phone. Please excuse brevity and lack of formatting.