On Tue, Jul 15, 2014 at 12:34 PM, Toshi Kani <toshi.kani@xxxxxx> wrote: > This RFC patchset is aimed to seek comments/suggestions for the design > and changes to support of Write-Through (WT) mapping. The study below > shows that using WT mapping may be useful for non-volatile memory. > > http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf > > There were idea & patches to support WT in the past, which stimulated > very valuable discussions on this topic. > > https://lkml.org/lkml/2013/4/24/424 > https://lkml.org/lkml/2013/10/27/70 > https://lkml.org/lkml/2013/11/3/72 > > This RFC patchset tries to address the issues raised by taking the > following design approach: > > - Keep the MTRR interface > - Keep the WB, WC, and UC- slots in the PAT MSR > - Keep the PAT bit unused > - Reassign the UC slot to WT in the PAT MSR > > There are 4 usable slots in the PAT MSR, which are currently assigned to: > > PA0/4: WB, PA1/5: WC, PA2/6: UC-, PA3/7: UC > > The PAT bit is unused since it shares the same bit as the PSE bit and > there was a bug in older processors. Among the 4 slots, the uncached > memory type consumes 2 slots, UC- and UC. They are functionally > equivalent, but UC- allows MTRRs to overwrite it with WC. All interfaces > that set the uncached memory type use UC- in order to work with MTRRs. > The PA3/7 slot is effectively unused today. Therefore, this patchset > reassigns the PA3/7 slot to WT. If MTRRs get deprecated in future, > UC- can be reassigned to UC, and there is still no need to consume > 2 slots for the uncached memory type. Note that MTRRs are already partially deprecated: all drivers *should* be using arch_phys_wc_add, not mtrr_add, and arch_phys_wc_add is a no-op on systems with working PAT. Unfortunately, I never finished excising mtrr_add. Finishing the job wouldn't be very hard. --Andy -- 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>