public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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