From: Sean V Kelley <seanvk@posteo.de>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH] drm/i915: Do not invalidate obj->pages under mempressure
Date: Mon, 09 Feb 2015 10:31:37 -0800 [thread overview]
Message-ID: <54D8FD09.70905@posteo.de> (raw)
In-Reply-To: <20150209164615.GD9837@nuc-i3427.alporthouse.com>
On 02/09/2015 08:46 AM, Chris Wilson wrote:
> On Sun, Feb 08, 2015 at 03:27:13PM -0800, Sean V Kelley wrote:
>>
>>
>> On 01/16/2015 08:05 PM, Daniel Vetter wrote:
>>> On Thu, Jan 15, 2015 at 08:44:00PM +0000, Chris Wilson wrote:
>>>> On Thu, Jan 15, 2015 at 08:36:15PM +0100, Daniel Vetter
>>>> wrote:
>>>>> On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson
>>>>> <chris@chris-wilson.co.uk> wrote:
>>>>>> This (partially) reverts
>>>>>>
>>>>>> commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author:
>>>>>> Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar
>>>>>> 25 13:23:06 2014 +0000
>>>>>>
>>>>>> drm/i915: Invalidate our pages under memory pressure
>>>>>
>>>>> Shouldn't we also revert the hunk in
>>>>> i915_gem_free_objects? Without the truncate vs. invalidate
>>>>> disdinction it seems to have lost it's reason for existence
>>>>> ...
>>>>
>>>> No, setting MADV_DONTNEED has other nice properties during
>>>> put_pages() - I think it is useful in its own right, for
>>>> example that is where my page stealing code goes...
>>>
>>> Well right now I can't make sense of this bit any more (tbh I
>>> didn't with the other code either, but overlooked that while
>>> reviewing). When it's just there for future work but atm dead
>>> code I prefer for it to get removed. -Daniel
>>
>>
>> So can we also revert the hunk in i915_gem_free_objects? I would
>> like to get this patch merged, it looks like that is the primary
>> concern.
>
> A problem I have is that the test written to hit the exact
> condition considered in the changelog does not ellict the bug.
>
> Can you test whether
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index
> 39e032615b31..6269204ba16f 100644 ---
> a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1030,6 +1030,7 @@
> i915_gem_execbuffer_move_to_active(struct list_head *vmas, /*
> update for the implicit flush after a batch */
> obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS; } +
> obj->dirty = 1; if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) {
> i915_gem_request_assign(&obj->last_fenced_req, req); if
> (entry->flags & __EXEC_OBJECT_HAS_FENCE) {
>
> makes the bug go away. If so, I think the bug is in the caller not
> setting reloc domains correctly. -Chris
Sure, I will take a look.
Thanks,
Sean
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-02-09 18:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 20:34 [PATCH] drm/i915: Do not invalidate obj->pages under mempressure Chris Wilson
2015-01-15 0:55 ` [Intel-gfx] " Daniel Vetter
2015-01-15 1:19 ` Sean V Kelley
2015-01-15 9:38 ` Chris Wilson
2015-01-15 2:11 ` shuang.he
2015-01-15 19:36 ` Daniel Vetter
2015-01-15 20:44 ` [Intel-gfx] " Chris Wilson
2015-01-17 4:05 ` Daniel Vetter
2015-02-08 23:27 ` [Intel-gfx] " Sean V Kelley
2015-02-09 16:46 ` Chris Wilson
2015-02-09 18:31 ` Sean V Kelley [this message]
2015-02-11 0:55 ` Sean V Kelley
2015-02-11 13:02 ` Daniel Vetter
2015-02-20 22:19 ` Sean V Kelley
2015-02-09 16:43 ` Daniel Vetter
2015-02-10 8:19 ` shuang.he
2015-02-10 11:38 ` Jani Nikula
2015-02-24 13:27 ` Jani Nikula
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=54D8FD09.70905@posteo.de \
--to=seanvk@posteo.de \
--cc=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.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.