From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Date: Wed, 15 Apr 2015 20:56:14 +0000 Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR Message-Id: <552ED06E.8030303@zytor.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andy Lutomirski , "Luis R. Rodriguez" , linux-rdma@vger.kernel.org Cc: Toshi Kani , Ingo Molnar , "linux-kernel@vger.kernel.org" , Hal Rosenstock , Sean Hefty , Suresh Siddha , Rickard Strandqvist , Mike Marciniszyn , Roland Dreier , Juergen Gross , Mauro Carvalho Chehab , Andy Walls , Borislav Petkov , Mel Gorman , Vlastimil Babka , Davidlohr Bueso , Dave Hansen , Jean-Christophe Plagniol-Villard , Thomas Gleixner , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Linux Fbdev development list , linux-media@vger.kernel.org, X86 ML On 04/15/2015 01:42 PM, Andy Lutomirski wrote: > > I disagree. We should try to NACK any new code that can't function > without MTRRs. > > (Plus, ARM is growing in popularity in the server space, and ARM quite > sensibly doesn't have MTRRs.) > Yes. People need to understand that MTRRs are fundamentally a transitional solution, a replacement for the KEN# logic in the P4 and P5 generation processors. The KEN# logic in the chipset would notify the CPU that a specific address should not be cached, without affecting the software (which may have been written for x86s built before caching existed, even.) MTRRs move this to the head end, so the CPU knows ahead of time what to do, as is required with newer architectures. It also enabled write combining in a transparent fashion. However, it is still transitional; it is there to describe the underlying constraints of the memory system so that code which doesn't use paging can run at all, but the only thing that can actually scale is PAT. -hpa