On Thu, 2018-04-19 at 16:12 -0700, Brian Stark wrote: > I was comparing different caching techniques using MTRR entries and I > found something strange. Note the output is from a basic utility that > uses mmap. > > NV Memory: > > Write-back > > Writes took 2075.993408 Megabytes per second > Reads took 2130.842529 Megabytes per second No Errors Found > > Write-Through > > Writes took 55.332256 Megabytes per second > Reads took 92.310310 Megabytes per second No Errors Found !!!I was > expecting this number to be the same as Write-back > > Uncached > > Writes took 55.331089 Megabytes per second > Reads took 92.315132 Megabytes per second No Errors Found > > Regular memory: > > Write-back > > Writes took 1875.560791 Megabytes per second > Reads took 2070.452637 Megabytes per second No Errors Found > > Write-Through > > Writes took 54.903713 Megabytes per second > Reads took 2106.244629 Megabytes per second No Errors Found !!!This > is what I expected to see for NV Memory > > Uncached > > Writes took 54.903923 Megabytes per second > Reads took 90.150986 Megabytes per second No Errors Found > > I am using the same driver (which adds MTRR entries to change caching > type) there is no physical reason why write through should behave > differently when using NV Memory. Does anybody on this mailing list > who may be more familiar with caching techniques know why this might > me the case?
I reran my old test and did not see this problem. So, I think there is an issue in your setup that it somehow ended up with UC... My test driver calls ioremap_wt to an NVDIMM range and access it from the driver itself. It does not modify MTRR entries. -Toshi _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
