Re: [PATCH v2] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

["Michał Winiarski" <michal.winiarski@intel.com>]

On Mon, Aug 31, 2015 at 07:42:34PM +0100, Chris Wilson wrote:
> On Mon, Aug 31, 2015 at 06:59:40PM +0200, Michał Winiarski wrote:
> > On each call to gen8_alloc_va_range_3lvl we're allocating temporary
> > bitmaps needed for error handling. Unfortunately, when we increase
> > address space size (48b ppgtt) we do additional (512 - 4) calls to
> > kcalloc, increasing latency between exec and actual start of execution
> > on the GPU. Let's just do a single kcalloc and setup proper offsets in
> > an array, we can also drop the size from free_gen8_temp_bitmaps since
> > it's no longer needed.
> > 
> > v2: Use GFP_TEMPORARY to make the allocations reclaimable.
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Cc: Michel Thierry <michel.thierry@intel.com>
> > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> 
> Is there any reason why it remains a 2D array though? Looks like it can
> be reduced to a single block. And why do we allocate a bitmap for the
> whole address space rather than just the range being allocated?

No particular reason, let's try that.
It's not the whole address space... Quite possibly just 1/512 of the whole
address space, as the PUD is handled in gen8_alloc_va_range_4lvl. I guess it was
done to simplify... something, although I can't tell what at this point.
 
> While you may just answer the questions posed, this looks clumsy:

Yup - missed that, I was using temp variable before sending the patch.
-Michał

> 
> > +	*pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
> > +			sizeof(unsigned long), GFP_TEMPORARY);
> > +	if (!*pts)
> > +		goto err_out;
> > +
> > +	for (i = 0; i < pdpes; i++)
> > +		pts[i] = *pts + i * BITS_TO_LONGS(I915_PDES);
> 
> i..e
> 
> for (i = 1; i < pdpes; i++)
> 	pts[i] = pts[0] + i* BITS_TO_LONGS(I915_PDES);
> 
> raises fewer questions.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx