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? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
