From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [PATCH] drm/ttm: Don't evict BOs outside of the requested placement range Date: Tue, 14 Oct 2014 15:10:00 +0900 Message-ID: <543CBE38.3000400@daenzer.net> References: <1412834579-24703-1-git-send-email-michel@daenzer.net> <86981c0ceeb66a579fb171b453f9dba1@slartibartfast.infiniteimprobability.net> <54375092.4040203@daenzer.net> <1412931090.16185.4.camel@ukfsn.org> <54379FE7.8040208@daenzer.net> <20141011183149.GE26941@phenom.ffwll.local> <20141011202412.GE29591@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail.gna.ch (darkcity.gna.ch [195.226.6.51]) by gabe.freedesktop.org (Postfix) with ESMTP id 4A9526E078 for ; Mon, 13 Oct 2014 23:10:06 -0700 (PDT) In-Reply-To: <20141011202412.GE29591@kroah.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Greg KH , Daniel Vetter Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 12.10.2014 05:24, Greg KH wrote: > On Sat, Oct 11, 2014 at 08:31:49PM +0200, Daniel Vetter wrote: >> On Fri, Oct 10, 2014 at 05:59:19PM +0900, Michel D=E4nzer wrote: >>> On 10.10.2014 17:51, Alan Swanson wrote: >>>> On Fri, 2014-10-10 at 12:20 +0900, Michel D=E4nzer wrote: >>>>> On 09.10.2014 19:22, Alan Swanson wrote: >>>>>> On 2014-10-09 07:02, Michel D=E4nzer wrote: >>>>>>> From: Michel D=E4nzer >>>>>>> >>>>>>> The radeon driver uses placement range restrictions for several rea= sons, >>>>>>> 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 sati= sfy >>>>>>> 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 th= is >>>>>>> much more noticeable than before. >>>>>>> >>>>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D84662 >>>>>>> Cc: stable@vger.kernel.org >>>>>>> Signed-off-by: Michel D=E4nzer >>>>>>> --- >>>>>>> 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 n= ew >>>>> 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. > > Yup, that's fine to do, it's what the scripts are for :) Okay, thanks guys for the clarification. -- = Earthling Michel D=E4nzer | http://www.amd.com Libre software enthusiast | Mesa and X developer