Quoting David Laight (2020-01-16 13:58:44) > From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Sent: 16 January 2020 12:29 > > > > Quoting David Laight (2020-01-16 12:26:45) > > > However there is a call from __i915_gem_objet_set_pages() that > > > is preceded by a lockdep_assert_held() check - so mustn't sleep. > > > > That is a mutex; it's allowed to sleep. The might_sleep() here should > > help assuage your fears. > > Gah. Having a mutex called mm.lock isn't entirely obvious when quickly > reading code. > > From what I was reading earlier it seems that clflush() (and cflushopt) > are fast (well not stupidly slow) for buffers under 4k. > I suspect then can do a 'mark pending', but for larger buffers have to > wait for earlier requests to complete (although the graph carries on > increasing to the 16k RH margin. > > If may well be that adding a cond_resched() after every 4k page > will have ~0 performance impact because the first few clflush > will be a bit faster (less slow). > > I'll do some measurements later this afternoon. > > FWIW does this code need to actually invalidate the cache lines? > Or is it just forcing a writeback? It is used for both. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
