[Intel-gfx] [PATCH] drm/i915: Make vm eviction uninterruptible

[Daniel Vetter]

On Tue, Apr 08, 2014 at 09:11:39PM -0700, Ben Widawsky wrote:
> On Tue, Apr 08, 2014 at 08:53:15AM +0200, Daniel Vetter wrote:
> > On Mon, Apr 7, 2014 at 11:58 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> > > Blocking important fixes for a test case is harmful to customers of our
> > > software. I won't argue past that. If you won't take it as is, add it to the
> > > JIRA task like you said. I'll carry this one around with my dynamic page table
> > > allocations since you essentially can't do any real workloads with full PPGTT
> > > without this (assuming you have signals). I'd venture to even say existing
> > > tests can hit it with full PPGTT turned on.
> > 
> > A duct-tape bugfix like this would be justified in late -rc, where the
> > risk for disabling full ppgtt would probably outweight this hack.
> > Earlier I'd opt of simply re-disbaling full ppgtt again if we can't
> > come up with a properly understood fix and testcase for it in time.
> > 
> > But atm full ppgtt is disabled, and we have a task-list with 10
> > subtasks on internal JIRA to knock down. Without that I wouldn't
> > recommend anyone to try to ship full ppgtt in production, especially
> > not our internal customers.
> > 
> > I've updated the relevant subtask JIRA with details.
> > -Daniel
> 
> I felt confident when I wrote the original email it was hittable without
> full PPGTT. I am not quite certain now. If that is not the case, I agree
> with you.

Yeah, all this is under the assumption that this only blows up with full
ppgtt.

Of course if we have an issue with normal operation as shipping in 3.15
then a small duct-tape patch until the real fix comes around does very
much look like a legit approach. Especially if we'd have users scaling our
walls already ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch