[Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects
Chris Wilson
chris at chris-wilson.co.uk
Fri Oct 14 12:54:20 UTC 2016
On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote:
>
> On 14/10/2016 13:18, Chris Wilson wrote:
> >+ gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >+ if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) {
> >+ /* 965gm cannot relocate objects above 4GiB. */
> >+ gfp &= ~__GFP_HIGHMEM;
> >+ gfp |= __GFP_DMA32;
> >+ }
> >+
> >+ do {
> >+ int order = min(fls(npages) - 1, max_order);
>
> I still have reservations on going back to max_order when previous
> chunks required an order decrease. Size of the object is unbound
> since it is indirectly controlled by userspace, correct? How about
> decreasing the max_order on every repeated order decrease, following
> failed order allocation?
> >+ struct page *page;
> >+
> >+ do {
> >+ page = alloc_pages(gfp | (order ? QUIET : 0), order);
> >+ if (page)
> >+ break;
> >+ if (!order--)
> >+ goto err;
Like:
/* Limit future allocations as well */
max_order = order;
> >+ } while (1);
We do pass NORETRY | NOWARN for the higher order allocations, so it
shouldn't be as bad it seems?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list