Re: [Intel-gfx] [PATCH] drm/mm: Break long searches in fragmented address spaces

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Andi Shyti (2020-02-11 22:56:44)
> Hi Chris,
> 
> On Fri, Feb 07, 2020 at 03:17:20PM +0000, Chris Wilson wrote:
> > We try hard to select a suitable hole in the drm_mm first time. But if
> > that is unsuccessful, we then have to look at neighbouring nodes, and
> > this requires traversing the rbtree. Walking the rbtree can be slow
> > (much slower than a linear list for deep trees), and if the drm_mm has
> > been purposefully fragmented our search can be trapped for a long, long
> > time. For non-preemptible kernels, we need to break up long CPU bound
> > sections by manually checking for cond_resched(); similarly we should
> 
> checking for "fatal signals" you mean?

We need to call schedule() ourselves for non-voluntary CONFIG_PREEMPT
kernels, and we need to escape from the kernel back to userspace to
handle a pending signal in this process.

Other applications, sysadmins tend to notice and complain about driver
hogging a CPU not letting anything else run; typically the user notices
that their application doesn't close on ^C.

(That is schedule() delays of a few ms will be noticed, but it takes a
couple of seconds before a user will become aware of a severe problem
with a stuck signal. :)

Now since responding to a signal itself may be expensive (we have to
restart the syscall and re-process all the state from before this
point), we make the trade-off here of only responding to a fatal-signal
(process exit), which should allow for faster system recovery under
pathological conditions.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx