Quoting Daniel Vetter (2020-01-16 06:52:42) > On Wed, Jan 15, 2020 at 08:52:45PM +0000, Chris Wilson wrote: > > Since we may try and flush the cachelines associated with large buffers > > (an 8K framebuffer is about 128MiB, even before we try HDR), this leads > > to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT). > > If we call cond_resched() between each sg chunk, that it about every 128 > > pages, we have a natural break point in which to check if the process > > needs to be rescheduled. Naturally, this means that drm_clflush_sg() can > > only be called from process context -- which is true at the moment. The > > other clflush routines remain usable from atomic context. > > > > Even though flushing large objects takes a demonstrable amount to time > > to flush all the cachelines, clflush is still preferred over a > > system-wide wbinvd as the latter has unpredictable latencies affecting > > the whole system not just the local task. > > > > Reported-by: David Laight <David.Laight@xxxxxxxxxx> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: David Laight <David.Laight@xxxxxxxxxx> > > The original bug report is complaining about latencies for SCHED_RT > threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure > it's terribly valid to cater to that use-case - all the desktop distros > seem a lot more reasonable. So firmly *shrug* from my side ... Yeah, I had the same immediate response to the complaint), but otoh we've inserted cond_resched() before when it looks like may consume entire jiffies inside a loop. At the very minimum, we should have a might_sleep() here and a reminder that this can be very slow (remember byt?). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
