Quoting Tvrtko Ursulin (2017-06-29 15:50:17)
>
> On 29/06/2017 14:49, Chris Wilson wrote:
> > When computing a hash for looking up relcoation target handles in an
> > execbuf, we start with a large size for the hashtable and proceed to
> > reduce it until the allocation suceeds. The final attempt is with an
> > order of 0 (i.e. a single element). This means that we then pass bits=0
> > to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
> > element. Right shifting by a value the width of the operand is
> > undefined, so limit the smallest hash table we use to order 1.
> >
> > Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to vma")
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 +++++++++++-----------
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 718bb75ad387..54791bcb8ccb 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -296,12 +296,8 @@ static int eb_create(struct i915_execbuffer *eb)
> > break;
> > } while (--size);
> >
> > - if (unlikely(!eb->buckets)) {
> > - eb->buckets = kzalloc(sizeof(struct hlist_head),
> > - GFP_TEMPORARY);
>
> Want to maybe drop the NORETRY | NOWARN from the remaining allocation
> now? Wasn't it recently discussed that it is to feeble in it's attempts
> to allocate?
True that was the point of the allocate afterwards, so that we could do
it with the retry flags. Time for a respin.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
