intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
Date: Thu, 24 Mar 2016 14:33:32 +0000	[thread overview]
Message-ID: <56F3FABC.8030903@intel.com> (raw)
In-Reply-To: <20160324134234.GM27742@nuc-i3427.alporthouse.com>

On 24/03/16 13:42, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
>> If we arm the release timer on acquiring the forcewake, we will release
>> the forcewake on the jiffie afterwards. If we only arm the release timer
>> on the final put, we will release the forcewake slightly later instead.
>>
>> Much, much worse, we did not acquire a refcount for the armed timing
>> during the get(), and so unbalanced our forcewake counting.
>>
>> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_uncore.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
>> index 96799392c2c7..d857168c6c9b 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
>>   static inline void
>>   fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
>>   {
>> +	d->wake_count++;
>>   	mod_timer_pinned(&d->timer, jiffies + 1);
>
> Which raise the obvious issue that we double increment the counter if
> the timer was pending (where we would only then release it once).
> -Chris

'jiffies + 1' might be only a nanosecond away; would it be better to use 
'jiffies + 2'? OTOH that might be quite a long time and therefore 
increase power consumption :( So is there a somewhat higher-resolution 
cyclic timer that we could use?

Also, why mod_timer_pinned() ? I'd think that if this actually happens a 
whole jiffie later, there'd be little correlation between the current 
CPU activity and what's happening when the timer fires, so no real point 
in pinning the timer to current CPU.

Using mod_timer() instead would allow it to apply slack and align the 
callback to other timer activity, maybe reducing CPU overhead at the 
possible cost of a slight increase in GPU power.

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-03-24 14:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24 13:32 [PATCH] drm/i915: Only arm the forcewake release timer on the final put Chris Wilson
2016-03-24 13:42 ` Chris Wilson
2016-03-24 13:54   ` Tvrtko Ursulin
2016-03-24 14:19     ` Chris Wilson
2016-03-24 14:30       ` Chris Wilson
2016-03-24 14:33   ` Dave Gordon [this message]
2016-03-24 14:55     ` Chris Wilson
2016-03-24 13:56 ` [PATCH v2] " Chris Wilson
2016-03-24 14:38 ` [PATCH] " Dave Gordon
2016-03-24 15:03 ` ✗ Fi.CI.BAT: failure for drm/i915: Only arm the forcewake release timer on the final put (rev2) Patchwork
2016-03-24 15:51   ` Chris Wilson

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=56F3FABC.8030903@intel.com \
    --to=david.s.gordon@intel.com \
    --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;
as well as URLs for NNTP newsgroup(s).