| |||||||||||||
Getting a handle on cachingGetting a handle on cachingPosted May 15, 2008 13:50 UTC (Thu) by arjan (subscriber, #36785)In reply to: Getting a handle on caching by sergey Parent article: Getting a handle on caching
PAT isn't about performance per se. Until now, the kernel uses MTRR and while that's a tad slow, it's done once during X startup, and pretty much static afterwards... (and "tad slow" is not human-noticable at all, it's way below that) The real problem is that the number of MTRR entries is very limited (8 on Intel CPUs for example); this is in fact so few that BIOSes increasingly will need/use all 8 just to map the existing system, so there's no new ones available for X in such a case..... PAT is the only option then to get write-combinable memory. So *if* you hit the "8 limit", it's a big performance thing, but if you don't hit the limit... you'll not notice the difference.
(Log in to post comments)
Getting a handle on caching Posted May 15, 2008 19:43 UTC (Thu) by ebiederm (subscriber, #35028) [Link] MTRRs can be setup in an overlapping mode where UC MTRRs trump WB MTRRs. In that case even if there are spare MTRRs the only way we can get WC memory regions is to through the use of PAT. BIOS's do that even on Boxes where it isn't strictly necessary to avoid going over the 8 MTRR limit. Other details. WC (write combining) technically allows read combining as well. Just none of the current instructions take advantage of that fact. Where PAT really wins is if you have a several high performance cards in your system that want to take advantage of WC. Which they can't do today because of the limitation in PAT resources. WC when the hardware takes advantage of it can be a real performance win. In one extreme example I saw a specialized low latency network card generate line rate 8Gpbs traffic directly from the cpu without touching memory. So it is very nice when you can get it. Eric
|
|||||||||||||