On Fri, Oct 10, 2014 at 05:59:19PM +0900, Michel Dänzer wrote: > On 10.10.2014 17:51, Alan Swanson wrote: > >On Fri, 2014-10-10 at 12:20 +0900, Michel Dänzer wrote: > >>On 09.10.2014 19:22, Alan Swanson wrote: > >>>On 2014-10-09 07:02, Michel Dänzer wrote: > >>>>From: Michel Dänzer <michel.daenzer@xxxxxxx> > >>>> > >>>>The radeon driver uses placement range restrictions for several reasons, > >>>>in particular to make sure BOs in VRAM can be accessed by the CPU, e.g. > >>>>during a page fault. > >>>> > >>>>Without this change, TTM could evict other BOs while trying to satisfy > >>>>the requested placement, even if the evicted BOs were outside of the > >>>>requested placement range. Doing so didn't free up any space in the > >>>>requested placement range, so the (potentially high) eviction cost was > >>>>incurred for no benefit. > >>>> > >>>>Nominating for stable because radeon driver changes in 3.17 made this > >>>>much more noticeable than before. > >>>> > >>>>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662 > >>>>Cc: stable@xxxxxxxxxxxxxxx > >>>>Signed-off-by: Michel Dänzer <michel.daenzer@xxxxxxx> > >>>>--- > >>>> drivers/gpu/drm/ttm/ttm_bo.c | 20 +++++++++++++++++--- > >>>> 1 file changed, 17 insertions(+), 3 deletions(-) > >>>> > >>[...] > >> > >>>I believe you need to "s/place/placement/" over this patch. > >> > >>The fpfn and lpfn members were moved from struct ttm_placement to a new > >>struct ttm_place in f1217ed09f827e42a49ffa6a5aab672aa6f57a65. > >> > >>If you mean something else, please elaborate. > > > >This patch failed to build on 3.17.0 so wouldn't be a candidate for > >stable unless the currently drm-next only ttm_place patch also goes to > >stable (else replace ttm_place with ttm_placements in the patch for > >stable)? > > Right, I guess I should drop the Cc: stable then and submit a manual > backport of it to the stable list once it has landed in Linus' tree. I've thought it's ok to cc: stable a patch - Greg's scripts will send you a mail as a nice reminder if the patch fails to apply. At least we regularly pull this stunt with i915 patches. Cc'ing Greg for clarification. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
