[Intel-gfx] [PATCH 01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait

[Tvrtko Ursulin]

On 23/07/2020 21:32, Dave Airlie wrote:
> I've got a 66 patch series here, does it have a cover letter I missed?
 >
 > Does it have a what is the goal of this series? Does it tell the
 > reviewer where things are headed and why this is a good idea from a
 > high level.

Chris sent it on one of the previous rounds upon my request - please see 
https://www.spinics.net/lists/intel-gfx/msg243461.html. First paragraph 
is the key.

This series of 66 is some other unrelated work which is a bit 
misleading, but that the usual. :) Real amount of patches is more around 
20, like that posting which had a cover letter.

> The problem with these series is they are impossible to review from a
> WTF does it do, and it forces people to review at a patch level, but
> the high level concepts and implications go unmissed.

I've been reviewing both implementations so in case it helps I'll write 
a few words... We had internal discussions and meetings on two different 
approaches. With this in mind, I agree it is hard to get the full 
picture looking from the outside when only limited amount of information 
went out (in the for of the cover letter).

In short, core idea the series is doing is splitting out object backing 
store reservation from address space management. This way it is able to 
collect all possible backing store (and kernel memory allocations) into 
this first stage, and it also does not have to feed the ww context down 
the stack. (Because parts lower in the stack can therefore never try to 
obtain a new buffer objects, or do memory allocation.)

To me that sounds a solid approach which is in line with obj dma_resv 
locking rules.

And it definitely is not to be reviewed (just) on the patch-per-patch 
basis. Applying all of it and looking at the end result is what is 
needed and what I have done first before proceeded to look at individual 
patches.

Regards,

Tvrtko