dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Alan Swanson <swanson@ukfsn.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: Don't evict BOs outside of the requested placement range
Date: Fri, 10 Oct 2014 17:59:19 +0900	[thread overview]
Message-ID: <54379FE7.8040208@daenzer.net> (raw)
In-Reply-To: <1412931090.16185.4.camel@ukfsn.org>

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@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@vger.kernel.org
>>>> Signed-off-by: Michel Dänzer <michel.daenzer@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

  reply	other threads:[~2014-10-10  8:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09  6:02 [PATCH] drm/ttm: Don't evict BOs outside of the requested placement range Michel Dänzer
2014-10-09  9:53 ` Christian König
2014-10-09 10:22 ` Alan Swanson
2014-10-10  3:20   ` Michel Dänzer
2014-10-10  8:51     ` Alan Swanson
2014-10-10  8:59       ` Michel Dänzer [this message]
2014-10-11 18:31         ` Daniel Vetter
2014-10-11 20:24           ` Greg KH
2014-10-14  6:10             ` Michel Dänzer
2014-10-10  9:03 ` [PATCH v2] " Michel Dänzer
2014-10-13 18:22 ` [PATCH] " Alex Deucher
2014-10-14  5:40   ` Thomas Hellstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54379FE7.8040208@daenzer.net \
    --to=michel@daenzer.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=swanson@ukfsn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox