On Mon, 16 Dec 2019 at 12:26, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
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 <matthew.auld@xxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
