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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
