What is the point of 1G+MTRR? If there are caching differences the TLB will fracture the pages anyway. Tejun Heo <tj@xxxxxxxxxx> 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. -- 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
