[PATCH] drm/i915: Demote drop_caches_set print

[PATCH] drm/i915: Demote drop_caches_set print

[Ben Widawsky]

Many tests call this ad naseum now (in an infinite loop, very often).
It clutters the logs. Actually, I'd rather drop it completely...

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 7008aac..d24e7d1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2657,7 +2657,7 @@ i915_drop_caches_set(void *data, u64 val)
 	struct i915_vma *vma, *x;
 	int ret;
 
-	DRM_DEBUG_DRIVER("Dropping caches: 0x%08llx\n", val);
+	DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
 
 	/* No need to check and wait for gpu resets, only libdrm auto-restarts
 	 * on ioctls on -EAGAIN. */
-- 
1.8.4.2

Re: [PATCH] drm/i915: Demote drop_caches_set print

[Daniel Vetter]

On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> Many tests call this ad naseum now (in an infinite loop, very often).
> It clutters the logs. Actually, I'd rather drop it completely...

Dropping it completely seems like the right solutions due to those "drop
caches in an infinite loop" kind of tests.
-Daniel

> 
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7008aac..d24e7d1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2657,7 +2657,7 @@ i915_drop_caches_set(void *data, u64 val)
>  	struct i915_vma *vma, *x;
>  	int ret;
>  
> -	DRM_DEBUG_DRIVER("Dropping caches: 0x%08llx\n", val);
> +	DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
>  
>  	/* No need to check and wait for gpu resets, only libdrm auto-restarts
>  	 * on ioctls on -EAGAIN. */
> -- 
> 1.8.4.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm/i915: Demote drop_caches_set print

[Chris Wilson]

On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote:
> On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> > Many tests call this ad naseum now (in an infinite loop, very often).
> > It clutters the logs. Actually, I'd rather drop it completely...
> 
> Dropping it completely seems like the right solutions due to those "drop
> caches in an infinite loop" kind of tests.

By that argument we should remove all log messages. Why are we doing
this ad nausem? I thought the recent intention was to call it around
tests, in which case the debug log would be busy enough to hide this
noise. (Noise until it is vital to explain some behavioural artifact.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915: Demote drop_caches_set print

[Daniel Vetter]

On Wed, Nov 06, 2013 at 09:19:42AM +0000, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> > > Many tests call this ad naseum now (in an infinite loop, very often).
> > > It clutters the logs. Actually, I'd rather drop it completely...
> > 
> > Dropping it completely seems like the right solutions due to those "drop
> > caches in an infinite loop" kind of tests.
> 
> By that argument we should remove all log messages. Why are we doing
> this ad nausem? I thought the recent intention was to call it around
> tests, in which case the debug log would be busy enough to hide this
> noise. (Noise until it is vital to explain some behavioural artifact.)

Some tests fork a 2nd thread which calls this in a busy loop. Together
with using gtt mmaps for ioctl data it's a very effective means to hit the
slowpath maze in our execbuf code. Iirc without this at least some of the
older bugs wouldn't be possible to hit (namely the slowpath of the
writeout of the updated gtt offset in the slow relocation path that we've
killed since it's too hard).

Generally I agree with you, but since I abuse this facility rather badly
in some tests I guess we should drop the debug output.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch