public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Vetter <daniel@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] pm_rps: Require that cur reaches min at idle
Date: Thu, 23 Jan 2014 19:49:20 +0100	[thread overview]
Message-ID: <20140123184920.GY9772@phenom.ffwll.local> (raw)
In-Reply-To: <20140123171542.GH14542@jeffdesk>

On Thu, Jan 23, 2014 at 11:15:42AM -0600, Jeff McGee wrote:
> On Thu, Jan 23, 2014 at 11:40:18AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 21, 2014 at 05:14:34PM -0600, jeff.mcgee@intel.com wrote:
> > > From: Jeff McGee <jeff.mcgee@intel.com>
> > > 
> > > The current frequency should reach the minimum frequency within a
> > > reasonable time during idle. We hold forcewake to prevent interference
> > > from sleep states.
> > > 
> > > Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
> > > ---
> > >  tests/pm_rps.c | 34 ++++++++++++++++++++++++++++++----
> > >  1 file changed, 30 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> > > index 7ae0438..50c66ee 100644
> > > --- a/tests/pm_rps.c
> > > +++ b/tests/pm_rps.c
> > > @@ -33,6 +33,7 @@
> > >  #include <unistd.h>
> > >  #include <getopt.h>
> > >  #include "drmtest.h"
> > > +#include "igt_debugfs.h"
> > >  
> > >  static bool verbose = false;
> > >  
> > > @@ -57,6 +58,9 @@ struct junk {
> > >  	{ "cur", "r", NULL }, { "min", "rb+", NULL }, { "max", "rb+", NULL }, { "RP0", "r", NULL }, { "RP1", "r", NULL }, { "RPn", "r", NULL }, { NULL, NULL, NULL }
> > >  };
> > >  
> > > +static igt_debugfs_t dfs;
> > > +static FILE *forcewake;
> > > +
> > >  static int readval(FILE *filp)
> > >  {
> > >  	int val;
> > > @@ -206,17 +210,33 @@ static void min_max_config(void (*check)(void))
> > >  	check();
> > >  }
> > >  
> > > +#define IDLE_WAIT_TIMESTEP_MSEC 100
> > > +#define IDLE_WAIT_TIMEOUT_MSEC 3000
> > >  static void idle_check(void)
> > >  {
> > >  	int freqs[NUMFREQ];
> > > -
> > > -	read_freqs(freqs);
> > > -	dump(freqs);
> > > -	checkit(freqs);
> > > +	int wait = 0;
> > > +
> > > +	/* Monitor frequencies until cur settles down to min, which should
> > > +	 * happen within the allotted time */
> > > +	do {
> > > +		read_freqs(freqs);
> > > +		dump(freqs);
> > > +		checkit(freqs);
> > > +		if (freqs[CUR] == freqs[MIN])
> > > +			break;
> > > +		usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
> > > +		wait += IDLE_WAIT_TIMESTEP_MSEC;
> > > +	} while (wait < IDLE_WAIT_TIMEOUT_MSEC);
> > > +
> > > +	igt_assert(freqs[CUR] == freqs[MIN]);
> > > +	log("Required %d msec to reach cur=min\n", wait);
> > >  }
> > >  
> > >  static void pm_rps_exit_handler(int sig)
> > >  {
> > > +	fclose(forcewake);
> > > +
> > >  	if (origfreqs[MIN] > readval(stuff[MAX].filp)) {
> > >  		writeval(stuff[MAX].filp, origfreqs[MAX]);
> > >  		writeval(stuff[MIN].filp, origfreqs[MIN]);
> > > @@ -287,6 +307,12 @@ int main(int argc, char **argv)
> > >  
> > >  		read_freqs(origfreqs);
> > >  
> > > +		/* Hold forcewake throughout test to prevent sleep states from
> > > +		 * interfering with evaluation of performance state management */
> > > +		igt_require(igt_debugfs_init(&dfs) == 0);
> > > +		forcewake = igt_debugfs_fopen(&dfs, "i915_forcewake_user", "r");
> > > +		igt_require(forcewake);
> > 
> > That smells like a hack to work around broken kernels ... Why exactly do
> > we need this? Also, recent upstream should auto-deboost to the lowest freq
> > on idle systems to avoid the gpu ending up stuck at higher frequencies.
> > -Daniel
> 
> I guess I'm a little unclear on the policy here. My understanding is that it
> is acceptable for the requested frequency to remain above min if we are in
> RC6, because the actual frequency is 0 MHz in that state and so we are
> getting the most power savings anyway. With this in mind, I didn't want to
> fail a system in which that occurred. Taking the forcewake allows us to
> verify that turbo hardware is working correctly on its own merits
> (particularly the interrupts). If the policy is to require that requested
> frequency always go to min at idle (RC6 or not), then I will remove the
> forcewake.

We've learned the hard way that the hardware can get stuck, so having such
a testcase (maybe as a separate subtest, you already add tons of other
interface checks in your series here) would be rather useful. It's not a
hard requirement but imo a good sanity check on our code (and on recent
kernels we should force the gt to the lowest frequency already when idle).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-01-23 18:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 23:14 Expansion of pm_rps subtest min-max-config-at-idle jeff.mcgee
2014-01-21 23:14 ` [PATCH 1/4] pm_rps: Expand on min and max config testing jeff.mcgee
2014-01-21 23:14 ` [PATCH 2/4] pm_rps: Remove repeat sysfs reads jeff.mcgee
2014-01-21 23:14 ` [PATCH 3/4] pm_rps: Make frequency logging more compact jeff.mcgee
2014-01-21 23:14 ` [PATCH 4/4] pm_rps: Require that cur reaches min at idle jeff.mcgee
2014-01-23 10:40   ` Daniel Vetter
2014-01-23 17:15     ` Jeff McGee
2014-01-23 18:49       ` Daniel Vetter [this message]
2014-01-23 20:24         ` Jeff McGee
2014-01-23 21:54           ` [PATCH 4/4 v2] " jeff.mcgee
2014-01-25 19:46             ` Daniel Vetter
2014-01-27 16:24               ` Jeff McGee
2014-01-27 16:50                 ` Daniel Vetter
2014-01-27 22:23                   ` Jeff McGee
2014-01-27 22:39                     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140123184920.GY9772@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox