On Wed, 8 Jul 2020 at 14:48, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>
> We removed retiring requests from the shrinker in order to decouple the
> mutexes from reclaim in preparation for unravelling the struct_mutex.
> The impact of not retiring is that we are much less agressive in making
> global objects available for shrinking, as such objects remain pinned
> until they are flushed by a heartbeat pulse following the last retired
> request along their timeline. In order to ensure that pulse occurs in
> time for memory reclamation, we should kick it from kswapd.
>
> The catch is that we have added some flush_work() into the retirement
> phase (to ensure that we reach a global idle in a timely manner), but
> these flush_work() are not eligible (i.e do not belong to WQ_MEM_RELCAIM)
> for use from inside kswapd. To avoid flushing those workqueues, we teach
> the retirer not to do so unless we are actually waiting, and only do the
> plain retire from inside the shrinker.
>
> Note that for execlists, we already retire completed contexts as they
> are scheduled out, so it should not be keeping global state
> unnecessarily pinned. The legacy ringbuffer however...
>
> References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker paths")
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
