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
next prev 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).