Bug 94852 - [SKL] rc6_residency_ms unreliable
Summary: [SKL] rc6_residency_ms unreliable
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-07 03:38 UTC by Len Brown
Modified: 2018-04-22 15:50 UTC (History)
2 users (show)

See Also:
i915 platform: HSW, SKL
i915 features: power/Other


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Len Brown 2016-04-07 03:38:41 UTC
Kernel: Linux-4.6.0-rc1

Hardware: SKL, HSW

Description:
Value read from /sys/class/drm/card0/power/rc6_residency_ms
resets before it reaches 5500 seconds.

This make it "somewhat awkward" to calculate residence from this counter,
since it can effectively go backwards - or worse, appear to increment
extremely slowly when it should really be incrementing quickly.

turbostat has a workaround for former, but there is no workaround
for the later.  powertop does not have a workaround, it will just
occasionally display garbage.

Debug steps taken:
booted both the SKL and HSW with cmdline "i915.enable_dc=0"
but it made no difference.

To Reproduce:
while /bin/true; do cat /sys/class/drm/card0/power/rc6_residency_ms; sleep 1; done
...
5491367
5492352
5493334
5494326
5495307
5496299
5497280
703
1685
2677
3658
4650
5631
6612
Comment 1 Jani Nikula 2016-04-07 09:26:47 UTC
The source of the information is GEN6_GT_GFX_RC6, a 32-bit register containing the residency since boot in units of 1.28 us. The register wraps around at about 5497.6 seconds, consistent with the report.
Comment 2 Chris Wilson 2016-04-07 11:43:52 UTC
For discussion: https://patchwork.freedesktop.org/patch/79932/
Comment 3 yann 2017-03-03 13:38:22 UTC
Reference to Mika's patch: https://patchwork.freedesktop.org/series/20578/
Comment 4 Jari Tahvanainen 2017-04-10 13:03:24 UTC
Len - related to solution ongoing (see comment 3). Would that work for your case?
Comment 5 Chris Wilson 2017-04-10 13:14:55 UTC
(In reply to Jari Tahvanainen from comment #4)
> Len - related to solution ongoing (see comment 3). Would that work for your
> case?

No. If the bug was opened because it is awkward to handle a wrap at 90 minutes, a wrap at 50 minutes is still not good enough.
Comment 6 Len Brown 2017-04-13 07:22:18 UTC
turbostat does not poll, it reads the value at the start
of a measurement interval, and then reads it again at the end.

the measurement interval can be of arbitrary length,
(and multiple copies of turbostat could be running at
 the same time with different measurement intervals)

turbostat has a sanity check that the ending value is not
smaller than the starting value, but that detects only 1 wrap,
and if there have been multiple wraps, it will print
erroneous results.

turbostat opens and closes the sysfs file for each of these reads.

Yes, this problem is much more in-your-face on BYT,
which appears to have a wrap at about 13 seconds (Linux-4.10) 

while /bin/true; do cat /sys/class/drm/card0/power/rc6_residency_ms; sleep 1; done
1394
2408
3423
4436
5451
6463
7474
8488
9503
10516
11529
12542
671
1685
2699
3713
4727
5741
6753
7767
8781
9794
10807
11821
12835
964
1977
2992
4005
5018
6032
7046
8060
9073
10087
11101
12114
243
1255
2268
3283
4295
5309
6323
7334
8349
9363
10374
11386
12401
529
Comment 7 Jani Saarinen 2018-03-29 07:11:58 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 8 Jani Saarinen 2018-04-22 15:50:32 UTC
Closing, please re-open if still occurs.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.