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. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
