Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-13 Thread Daniel Vetter
On Fri, Sep 13, 2013 at 2:59 AM, Rob Clark wrote: > I guess in i915 (and ttm) case, the issue arises due to need for CPU > access to buffer via GTT? In which case I should be safe to drop the > set_need_resched() as well? (Since CPU always has direct access to the > pages.) Or am I missing

Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-13 Thread Daniel Vetter
On Fri, Sep 13, 2013 at 2:59 AM, Rob Clark robdcl...@gmail.com wrote: I guess in i915 (and ttm) case, the issue arises due to need for CPU access to buffer via GTT? In which case I should be safe to drop the set_need_resched() as well? (Since CPU always has direct access to the pages.) Or am

Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Rob Clark
hmm, looks like I cargo-cult'd the same into msm. I guess in i915 (and ttm) case, the issue arises due to need for CPU access to buffer via GTT? In which case I should be safe to drop the set_need_resched() as well? (Since CPU always has direct access to the pages.) Or am I missing something

Re: [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Daniel Vetter
On Thu, Sep 12, 2013 at 05:59:51PM +0200, Peter Zijlstra wrote: > On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote: > > This is just a remnant from the old days when our reset handling was > > horribly racy, suffered from terribly locking issues and often happily > > live-locked.

[PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Daniel Vetter
This is just a remnant from the old days when our reset handling was horribly racy, suffered from terribly locking issues and often happily live-locked. Those days are now gone so we can drop the hacks and just rip the reschedule-point out. Reported-by: Peter Zijlstra Cc: Peter Zijlstra Cc:

Re: [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Peter Zijlstra
On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote: > This is just a remnant from the old days when our reset handling was > horribly racy, suffered from terribly locking issues and often happily > live-locked. Those days are now gone so we can drop the hacks and just > rip the

Re: [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Peter Zijlstra
On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote: This is just a remnant from the old days when our reset handling was horribly racy, suffered from terribly locking issues and often happily live-locked. Those days are now gone so we can drop the hacks and just rip the

[PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Daniel Vetter
This is just a remnant from the old days when our reset handling was horribly racy, suffered from terribly locking issues and often happily live-locked. Those days are now gone so we can drop the hacks and just rip the reschedule-point out. Reported-by: Peter Zijlstra pet...@infradead.org Cc:

Re: [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Daniel Vetter
On Thu, Sep 12, 2013 at 05:59:51PM +0200, Peter Zijlstra wrote: On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote: This is just a remnant from the old days when our reset handling was horribly racy, suffered from terribly locking issues and often happily live-locked. Those days

Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

2013-09-12 Thread Rob Clark
hmm, looks like I cargo-cult'd the same into msm. I guess in i915 (and ttm) case, the issue arises due to need for CPU access to buffer via GTT? In which case I should be safe to drop the set_need_resched() as well? (Since CPU always has direct access to the pages.) Or am I missing something