public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: jeff.mcgee@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4 v2] pm_rps: Require that cur reaches min at idle
Date: Sat, 25 Jan 2014 20:46:45 +0100	[thread overview]
Message-ID: <20140125194645.GG9772@phenom.ffwll.local> (raw)
In-Reply-To: <1390514090-17875-1-git-send-email-jeff.mcgee@intel.com>

On Thu, Jan 23, 2014 at 03:54:50PM -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.
> 
> v2: Not using forcewake for this particular subtest per Daniel's
>     suggestion.
> 
> Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>

Hm, I guess I wasn't clear enough: I've thought about adding a new subtest
which just does the check that the actual frequency reaches the lowest
level on idle a new subtest, not extend the existing one.

Same somewhat holds for your first patch, atm the testcase is a very basic
test of the kernel error checking.

But even ignoring that I'm not really sure what you're aiming at. Imo the
current coverage is good enough since it makes sure that we have at least
a bit of error checking in place. Any extensions to this test should imo
only be done when we add new features or to exercise bugs (or classes of
bugs) that actually happened. Iirc (and I didn't check olds mails, so this
might be wrong) we have some corner-cases across suspend/resume and some
with the in-kernel code to adjust the requested frequency under load. So
imo that's what we should test for.

Reading through my test requirements write-up I've just noticed that I
didn't emphasis that there's also too much testing possible imho. I'm not
a big proponent of test driven developement and similar validate
everything approaches. I guess I need to write up my thoughts about too
much testing, too ;-)

Anyway I'm a bit confused about what's the overall goal here, so please
elaborate.

Cheers, Daniel

> --- tests/pm_rps.c | 22 ++++++++++++++++++---- 1 file changed, 18
> insertions(+), 4 deletions(-)
> 
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c index 7ae0438..24a1ad6
> 100644 --- a/tests/pm_rps.c +++ b/tests/pm_rps.c @@ -206,13 +206,27 @@
> 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) -- 1.8.5.2
> 
> _______________________________________________ Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

  reply	other threads:[~2014-01-25 19:46 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
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 [this message]
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=20140125194645.GG9772@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jeff.mcgee@intel.com \
    /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