On Fri, Aug 23, 2013 at 10:35:07AM -0400, Tejun Heo wrote: > Yeah, it's true that MTRRs are nasty. On the other hand, we've been > doing that for over a decade and are still doing it anyway if I'm not > mistaken. It probably isn't a big difference but it's still a bit sad > that this is likely causing small performance regression out in the > wild. Just went over the processor manual and it doesn't seem like doing the above would be a good idea. System Programming Guide, Part 1 11.11.9 Large Page Size Considerations ... Because the memory type for a large page is cached in the TLB, the processor can behave in an undefined manner if a large page is mapped to a region of memory that MTRRs have mapped with multiple memory types. ... If a large page maps to a region of memory containing different MTRR-defined memory types, the PCD and PWT flags in the page-table entry should be set for the most conservative memory type for that range. For example, a large page used for memory mapped I/O and regular memory 11-48 Vol. 3A MEMORY CACHE CONTROL ... The Pentium 4, Intel Xeon, and P6 family processors provide special support for the physical memory range from 0 to 4 MBytes, ... Here, the processor maps the memory range as multiple 4-KByte pages within the TLB. This operation insures correct behavior at the cost of performance. To avoid this performance penalty, operating-system software should reserve the large page option for regions of memory at addresses greater than or equal to 4 MBytes. So, yeah, the current behavior seems like the right thing to do. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>