On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie airlied@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.