From: "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>
To: Petr Vorel <pvorel@suse.cz>, "Kubaj, Piotr" <piotr.kubaj@intel.com>
Cc: "Ossowski, Tomasz" <tomasz.ossowski@intel.com>,
"Dubel, Helena Anna" <helena.anna.dubel@intel.com>,
"Niestepski, Daniel" <daniel.niestepski@intel.com>,
"ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v3] thermal: add new test group
Date: Thu, 29 Jan 2026 22:40:41 +0100 [thread overview]
Message-ID: <79fc9cb3-ea1f-40ab-ba6f-e7a7dd4f23eb@intel.com> (raw)
In-Reply-To: <20260123182822.GA367190@pevik>
On 1/23/2026 7:28 PM, Petr Vorel wrote:
> Hi Piotr,
>
>>>> Then it
>>>> + * decreases the threshold for sending a thermal interrupt to just
>>>> above
>>>> + * the current temperature and runs a workload on the CPU.
>>> First, why test needs to run for 30 sec and then sleep for 10 sec?
> Maybe the most important of my questions / points.
>
>> Here the point is to use a decreasing timeout. The test starts with 10s
>> cooldown to make sure that even pre-production CPU's, which might have
>> their thermal protections disabled, cool down properly. Once sleep time
>> reaches 0, the conclusion is that either there was not enough workload
>> or somehow interrupts are not triggered after all.
> Why 30 sec and then sleep for 10 sec? Is it really needed to do it this way?
Of course not.
> Aren't these times depending on the tested machine? Some of them will fail due
> time not running enough,
That's unexpected with the numbers that are used, so something is amiss
if it fails (and so it should fail).
> other will waste time (if they get interrupt e.g. in 10 sec).
That very well may happen, but is it a big deal?
> The usual approach would be to have the timeout safe enough for any type
> of hardware but proactively check the temperature and stop testing once it's
> done.
We want to create conditions in which the temperature should rise and if
it doesn't, then there is a problem.
That said, the temperature can of course be checked more proactively, at
least in principle, like say run cpu_workload() for 1s, check the
temperature, repeat that several times, then cool down etc.
BR, Rafael
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-02-02 13:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 13:41 [LTP] [PATCH v3] thermal: add new test group Piotr Kubaj
2026-01-22 14:07 ` Petr Vorel
2026-01-23 13:12 ` Kubaj, Piotr
2026-01-23 18:28 ` Petr Vorel
2026-01-29 21:40 ` Wysocki, Rafael J [this message]
2026-01-29 23:24 ` Petr Vorel
2026-02-03 14:38 ` Wysocki, Rafael J
-- strict thread matches above, loose matches on Subject: below --
2025-11-19 11:45 Piotr Kubaj
2025-11-20 16:30 ` Petr Vorel
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=79fc9cb3-ea1f-40ab-ba6f-e7a7dd4f23eb@intel.com \
--to=rafael.j.wysocki@intel.com \
--cc=daniel.niestepski@intel.com \
--cc=helena.anna.dubel@intel.com \
--cc=ltp@lists.linux.it \
--cc=piotr.kubaj@intel.com \
--cc=pvorel@suse.cz \
--cc=tomasz.ossowski@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