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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.