[Intel-gfx] [PATCH 2/9] drm/i915: Extract node allocation from bind

Chris Wilson chris at chris-wilson.co.uk
Wed May 7 17:53:08 CEST 2014


On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> On Wed, May 07, 2014 at 08:02:38AM +0100, Chris Wilson wrote:
> > On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> > > The DRM node allocation code was already a bit of an ugly bit of code
> > > within a complex function. Removing it serves the purpose of cleaning
> > > the function up. More importantly, it provides a way to have a
> > > preallocated (address space) VMA to easily skip this code. Something
> > > we're very likely to need.
> > > 
> > > This is essentially a wrapper for DRM node allocation with an eviction +
> > > retry. It is something which could be moved to core DRM eventually, if
> > > other drivers had similar eviction semantics.
> > > 
> > > This removes a goto used for something other than error unwinding, a
> > > generally reviled (I am neutral) practice, and replaces it with a
> > > function call to itself that should have the same effect. Note that it's
> > > not a recursive function as all the problem set reduction is done in the
> > > eviction code.
> > > 
> > > Some might say this change is worse than before because we are using
> > > stack for each subsequent call. Frankly, I'd rather overflow the stack
> > > and blow it up than loop forever. In either case, this is addressed in
> > > the next patch.
> > > 
> > > I believe, and intend, that other than the stack usage, there is no
> > > functional change here.
> > 
> > Nope, but decoupling evict_something() further does introduce lots more
> > implied magic.
> > -Chris
> > 
> 
> Hmm. I really don't see what's actually upsetting. Can you be a bit more
> explicit about what's so bothersome to you for my edification?

evict_something() make assumptions about the ranges of the vm which it
searches. At the moment, they mirror its parent's function.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list