On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie <airlied at gmail.com> wrote: [..] >>> Aren't there only 2 possibilities for this regression? >>> >>> 1/ a memtype entry was never made so track_pfn_insert() returns an >>> uncached mapping >>> >>> 2/ a conflicting memtype entry exists and undefined behavior due to >>> mixed mapping types is avoided with the change. >> >> 3/ The CPU usage through this path goes up, and slows things down, >> though I suspect you it's more an uncached mapping showing up >> when we don't expect it. > > It's looking line number 1, there is no mapping, now we get uncached > where we used to get write through. > > difference in page prot 7f7bbc0e0000, pfn 20000000000e71e4, > 8000000000000037, 800000000000002f > > 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned > pgprot which lacks that bit. > > not sure where to go from here, suggestions? If the driver established an ioremap_wt() across the range, or just called reserve_memtype() directly that should restore WT mappings. Although Daniel's suggestion to use the i915 mapping helpers sounds like it avoids problem 3/ as well.
