On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote:
>
> On 14/10/2016 13:54, Chris Wilson wrote:
> >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?
>
> I don't know for sure without looking into the implementation
> details. But I assumed even with NORETRY it does some extra work to
> try and free up the space. And if it fails, and we ask for it again,
> it is just doing that extra work for nothing. Because within a
> single allocation it sounds unlikely that something would change so
> dramatically that it would start working.
iirc, NORETRY means abort after failure. In effect, it does
2 attempts from the freelist, a direct reclaim, and may then repeat
if the task's allowed set of nodes were concurrently changed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
