[Intel-gfx] [PATCH 13/18] drm/i915: remove too-frequent FBC debug message

[chris at chris-wilson.co.uk]

On Wed, Oct 21, 2015 at 06:19:23PM +0000, Zanoni, Paulo R wrote:
> Em Qua, 2015-10-21 às 14:01 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:59AM -0200, Paulo Zanoni wrote:
> > > If we run igt/kms_frontbuffer_tracking, this message will appear
> > > thousands of times, eating a significant part of our dmesg buffer.
> > > It's part of the expected FBC behavior, so let's just silence it.
> > > 
> > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > 
> > Looks fine. Out of curiosity what metrics do we have for FBC
> > activity? I
> > presume we have tracepoints for activate/deactivate. and perhaps a sw
> > timer, and a hw debug register?
> 
> The most important metric is PC state residency, but that requires the
> machine to be properly configured: if SATA is preventing our machine
> from going deeper than PC3, FBC won't change PC state residencies.
> Also, our public processor datasheet docs mention the maximum expected
> PC states for the most common screen resolutions.
> 
> We can work on adding more things later, such as the tracepoints or
> software timer you mentioned. I've been 100% focused on getting the
> bugs out first. Is there anything specific you think you could use?

The tracepoints are primarily a debug tool, effectively less noisy
printks that can be easily hooked up to a bit of python for processing
(if just read huge logs isn't satisfying).

For monitoring efficacy, I had in mode a timer for fbc active and
perhaps one for timing compression (ideally the active timer would only
start when the compressed frame was complete, but that may be too much).
That should get us to the point where we can quickly see if we are
enabling FBC for significant periods. Now, this can be done with good
tracepoints and a userspace script. So really just planning good
coverage of tracepoints is the starting point.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre