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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.