On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On 17 October 2016 at 04:41, Marek Olšák <maraeo@xxxxxxxxx> wrote: >> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >>> >>> [ Adding Dan Williams and dri-devel ] >>> >>> On 14/10/16 03:28 AM, Shawn Starr wrote: >>>> Hello AMD folks, >>>> >>>> I have discovered a problem in Linus master that affects AMDGPU, nobody would >>>> notice this in drm-next-4.9-wip since its not in this repo. >>> >>> [...] >>> >>>> 87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit >>>> commit 87744ab3832b83ba71b931f86f9cfdb000d07da5 >>>> Author: Dan Williams <dan.j.williams@xxxxxxxxx> >>>> Date: Fri Oct 7 17:00:18 2016 -0700 >>>> >>>> mm: fix cache mode tracking in vm_insert_mixed() >>>> >>>> vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(), >>>> fails to check the pgprot_t it uses for the mapping against the one >>>> recorded in the memtype tracking tree. Add the missing call to >>>> track_pfn_insert() to preclude cases where incompatible aliased mappings >>>> are established for a given physical address range. >>>> >>>> Link: http://lkml.kernel.org/r/ >>>> 147328717909.35069.14256589123570653697.stgit@dwillia2- >>>> desk3.amr.corp.intel.com >>>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >>>> Cc: David Airlie <airlied@xxxxxxxx> >>>> Cc: Matthew Wilcox <mawilcox@xxxxxxxxxxxxx> >>>> Cc: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> >>>> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> >>>> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> >>>> >>>> :040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a >>>> fd497a604a2af5995db2b8ed1e9c640bede6adf3 M mm >>>> >>>> >>>> Removal of this patch stops graphics stalls. >>> >>> Thanks for bisecting this Shawn. >>> >>> >>>> A friend of mine mentions, >>>> >>>> "looks like a graphics thingy you depend on is requesting a mapping with a >>>> not-allowed cache mode, and now you are (rightfully) getting errors?" >>> >>> It would be nice to get some more specific pointers what amdgpu (or >>> maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be >>> doing wrong. > > /* > * We'd like to use VM_PFNMAP on shared mappings, where > * (vma->vm_flags & VM_SHARED) != 0, for performance reasons, > * but for some reason VM_PFNMAP + x86 PAT + write-combine is very > * bad for performance. Until that has been sorted out, use > * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719 > */ > vma->vm_flags |= VM_MIXEDMAP; > > We have that comment in the ttm code, which to me implies that mixed is > doing the right thing now, but that is slow, as the interface we > should be using. > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
