On Mon, 16 Dec 2019 at 12:26, Chris Wilson <[email protected]> wrote:
>
> When creating a handle, it is just that, an abstract handle. The fact
> that we cannot currently support a handle larger than the size of the
> backing storage is an artifact of our whole-object-at-a-time handling in
> get_pages() and being an implementation limitation is best handled at
> that point -- similar to shmem, where we only barf when asked to
> populate the whole object if larger than RAM. (Pinning the whole object
> at a time is major hindrance that we are likely to have to overcome in
> the near future.) In the case of the buddy allocator, the late check is
> preferable as the request size may often be smaller than the required
> size.
>
> Signed-off-by: Chris Wilson <[email protected]>
> Cc: Matthew Auld <[email protected]>
> Cc: Joonas Lahtinen <[email protected]>

I think we just need:

@@ -1420,7 +1420,7 @@ static int igt_ppgtt_smoke_huge(void *arg)

                err = i915_gem_object_pin_pages(obj);
                if (err) {
-                       if (err == -ENXIO) {
+                       if (err == -ENXIO || err == -E2BIG) {
                                i915_gem_object_put(obj);
                                size >>= 1;
                                goto try_again;

?

Or whatever takes your fancy,
Reviewed-by: Matthew Auld <[email protected]>
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to