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 at amd.com> >>>> >>>> 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 at vger.kernel.org >>>> Signed-off-by: Michel D?nzer <michel.daenzer at amd.com> >>>> --- >>>> 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. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
