On Mon, Jan 20, 2014 at 11:37:42AM +0100, Daniel Vetter wrote: > On Mon, Jan 20, 2014 at 09:49:24AM +0000, Chris Wilson wrote: > > On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote: > > > Also there's a certain chance we'll starve > > > the unpin work, similar to the issues around flushing the unpin work > > > in our pageflip implementation. > > > > If you mean that we will never run the unpin workqueue, that's what the > > implementation will fix, eventually, after a busy-spin in userspace since > > set_need_resched() was removed. I can teach userspace to yield() after > > an EAGAIN which seems a reasonable compromise (userspace gets a bonus > > for being cooperative rather than penalized for using up its timeslice.) > > yield won't help, we need to block on the work-queue draining like we do > in the pageflip code with flush_workqueue. At least we've had bug reports > in the past where someone found it intriguing to run his entire userspace > with rt prio, which ended up starving the sched_normal workqueue and so > livelocked the entire system. But isn't that exactly the behaviour the RT user programmed? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
