On Wed, 12 Dec 2012 12:18:35 +0200, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> On Fri, 07 Dec 2012, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > As we may reap neighbouring objects in order to free up pages for
> > allocations, we need to be careful not to allocate in the middle of the
> > drm_mm manager. To accomplish this, we can simply allocate the
> > drm_mm_node up front and then use the combined search & insert
> > drm_mm routines, reducing our code footprint in the process.
> >
> > Fixes (partially) i-g-t/gem_tiled_swapping
> >
> > Reported-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 64 +++++++++++++++++----------------------
> > 1 file changed, 27 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index c1f6919..d17f52d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2890,7 +2890,7 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
> > {
> > struct drm_device *dev = obj->base.dev;
> > drm_i915_private_t *dev_priv = dev->dev_private;
> > - struct drm_mm_node *free_space;
> > + struct drm_mm_node *node;
> > u32 size, fence_size, fence_alignment, unfenced_alignment;
> > bool mappable, fenceable;
> > int ret;
> > @@ -2936,66 +2936,56 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
> >
> > i915_gem_object_pin_pages(obj);
> >
> > + node = kzalloc(sizeof(*node), GFP_KERNEL);
> > + if (node == NULL) {
> > + i915_gem_object_unpin_pages(obj);
> > + return -ENOMEM;
> > + }
>
> Any reason not to do the kzalloc before i915_gem_object_pin_pages, with
> a slight simplification of the error path there?
No reason at all. In my defense, I was trying to make the code as similar
as possible...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
