On 14/10/2016 15:42, Chris Wilson wrote:
On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote:
On 14/10/2016 14:53, Chris Wilson wrote:
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.
Do you think it makes sense doing all that after it started failing,
within our single get_pages allocation?
I was thinking about skipping the DIRECT_RECLAIM for high order, but it
seems like that is beneficial for THP, so I'm presuming it should also
be for ourselves. Trimming back max_order seems sensible, but I still
like the idea of taking advantage of contiguous pages where possible
(primarily these will be used for ringbuffers and shadow batches).
Can we agree then to try larger order first and fall back gradually?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
