From: Mario Limonciello <superm1@kernel.org>
To: Luna Nova <ml-fd-amd-gfx-devel@nyx.nova.fail>,
amd-gfx@lists.freedesktop.org
Cc: Luke Jones <luke@ljones.dev>,
Mario Limonciello <mario.limonciello@amd.com>,
Alex Deucher <alexdeucher@gmail.com>
Subject: Re: [PATCH] drm/amd: Don't wake dGPUs while reading sensors
Date: Sun, 25 Aug 2024 19:19:28 -0500 [thread overview]
Message-ID: <26c4982a-c735-4a6e-829c-7d1a057aa4fe@kernel.org> (raw)
In-Reply-To: <de5eeddc-df9f-4c0d-aa11-8ad077bd8adb@app.fastmail.com>
On 8/25/24 15:40, Luna Nova wrote:
> Raised this as an issue a while back on the bug tracker and it got closed as WONTFIX. https://gitlab.freedesktop.org/drm/amd/-/issues/2229
> Been running a patched kernel with a similar patch locally ever since because even figuring out everything on the system that's accidentally waking the GPU was too time consuming.
>
> I'd love if this gets accepted.
> I think fundamentally waking the device to ask how much power it is using thus increasing the power usage makes no sense - by trying to measure it we changed it, so if power can't be measured while off it only makes sense to return an error. Same applies for other sensors that currently wake the GPU - most of them are changing the property by waking it.
>
> Because this behavior is odd and it's not obvious on single GPU systems that anything's going wrong app and lib devs are likely to keep making this "mistake" forever.
>
> Luna
So FWIW I did file a v2 [1] that "undoes" the debugfs changes.
[1]
https://lore.kernel.org/amd-gfx/20240823145527.150749-1-mario.limonciello@amd.com/
If there is too much push back to an error code another option we can do
is return "0" for this case, which will make "sense" for some sysfs
files specifically if in d3cold. However for d3hot and some sysfs it
isn't fully true.
prev parent reply other threads:[~2024-08-26 0:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 2:04 [PATCH] drm/amd: Don't wake dGPUs while reading sensors Mario Limonciello
2024-08-23 13:44 ` Hamza Mahfooz
2024-08-23 13:58 ` Mario Limonciello
2024-08-23 14:09 ` Alex Deucher
2024-08-23 14:13 ` Mario Limonciello
2024-08-23 14:31 ` Alex Deucher
2024-08-23 14:39 ` Mario Limonciello
2024-08-24 2:22 ` Luke Jones
2024-08-25 20:40 ` Luna Nova
2024-08-26 0:19 ` Mario Limonciello [this message]
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=26c4982a-c735-4a6e-829c-7d1a057aa4fe@kernel.org \
--to=superm1@kernel.org \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=luke@ljones.dev \
--cc=mario.limonciello@amd.com \
--cc=ml-fd-amd-gfx-devel@nyx.nova.fail \
/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