RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-24 Thread David Laight
From: Chris Wilson > Sent: 15 January 2020 20:53 > > 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_resche

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
> I'll do some measurements later this afternoon. This is an Ivy bridge cpu, so clflush (not clflushopt). With a cond_resched for every page I get: (Note these calls are every 10 seconds) # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | |

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
From: Chris Wilson > Sent: 16 January 2020 07:40 > Quoting Daniel Vetter (2020-01-16 06:52:42) > > On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote: > > > Since we may try and flush the cachelines associated with large buffers > > > (an 8K framebuffer is about 128MiB, even before we tr

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
From: Chris Wilson > 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() he

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-17 Thread David Laight
From: David Laight > Sent: 16 January 2020 14:41 > > I'll do some measurements later this afternoon. > > This is an Ivy bridge cpu, so clflush (not clflushopt). > With a cond_resched for every page I get: > (Note these calls are every 10 seconds) For comparison some times booted with the orig

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-16 Thread Chris Wilson
Quoting David Laight (2020-01-16 13:58:44) > From: Chris Wilson > > 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. > > > > T

RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-16 Thread Chris Wilson
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. -Chris _

Re: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Chris Wilson
Quoting Daniel Vetter (2020-01-16 06:52:42) > On Wed, Jan 15, 2020 at 08:52:45PM +, 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 (whe

Re: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Daniel Vetter
On Wed, Jan 15, 2020 at 08:52:45PM +, 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 co