[Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

[Chris Wilson]

Quoting Thomas Hellström (Intel) (2020-07-27 10:24:24)
> Hi, Chris,
> 
> It appears to me like this series is doing a lot of different things:
> 
> - Various optimizations
> - Locking rework
> - Adding schedulers
> - Other misc fixes
> 
> Could you please separate out as much as possible the locking rework 
> prerequisites in one series with cover letter, and most importantly the 
> major part of the locking rework (only) with a more elaborate cover 
> letter discussing, if not trivial, how each patch fits in and on design 
> and future directions, Questions that I have stumbled on so far (being a 
> new-to-the-driver reviewer):

The locking depend on the former work to reduce the impact. It's still a
major issue that we introduce a broad lock that is held for several
hundred milliseconds across many objects that stalls game&compositor.
 
> - When are memory allocations disallowed? If we need to pre-allocate in 
> execbuf, when? why?

That should be mentioned in the code.

> - When is the request dma-fence published?

There a big comment to that effect.

> - Do we need to keep cpu asynchronous execbuf tasks after this? why?

Keep? Oh, you mean not immediately discard after publishing them, but
why we need them. Same reason as we need them before.

> - What about userptr pinning ending up in the dma_fence critical path?

It's in the user critical path (the shortest path to perform their
sequence of operations), but it's before the dma-fence itself. I say
that's a particularly nasty false claim that it is not on the critical
path, but being where it is circumvents the whole argument.
 
> And then move anything non-related to separate series?

Not related to what? Development of i915?
-Chris