linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pratik Sampat <psampat@linux.ibm.com>
To: Doug Smythies <dsmythies@telus.net>
Cc: rjw@rjwysocki.net, Daniel Lezcano <daniel.lezcano@linaro.org>,
	shuah@kernel.org, ego@linux.vnet.ibm.com, svaidy@linux.ibm.com,
	Linux PM list <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-kselftest@vger.kernel.org, pratik.r.sampat@gmail.com
Subject: Re: [RFC v3 0/2] CPU-Idle latency selftest framework
Date: Fri, 9 Apr 2021 13:13:06 +0530	[thread overview]
Message-ID: <0a4b32e0-426e-4886-ae37-6d0bdafdea7f@linux.ibm.com> (raw)
In-Reply-To: <CAAYoRsWaAmyuJU4FCb7gtK0y-ZprdDVvp0vMpy=ZohzoC7YX1Q@mail.gmail.com>

Hello Doug,

On 09/04/21 10:53 am, Doug Smythies wrote:
> Hi Pratik,
>
> I tried V3 on a Intel i5-10600K processor with 6 cores and 12 CPUs.
> The core to cpu mappings are:
> core 0 has cpus 0 and 6
> core 1 has cpus 1 and 7
> core 2 has cpus 2 and 8
> core 3 has cpus 3 and 9
> core 4 has cpus 4 and 10
> core 5 has cpus 5 and 11
>
> By default, it will test CPUs 0,2,4,6,10 on cores 0,2,4,0,2,4.
> wouldn't it make more sense to test each core once?

Ideally it would be better to run on all the CPUs, however on larger systems
that I'm testing on with hundreds of cores and a high a thread count, the
execution time increases while not particularly bringing any additional
information to the table.

That is why it made sense only run on one of the threads of each core to make
the experiment faster while preserving accuracy.

To handle various thread topologies it maybe worthwhile if we parse
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list for each core and
use this information to run only once per physical core, rather than
assuming the topology.

What are your thoughts on a mechanism like this?

> With the source CPU always 0, I think the results from the results
> from the destination CPUs 0 and 6, on core 0 bias the results, at
> least in the deeper idle states. They don't make much difference in
> the shallow states. Myself, I wouldn't include them in the results.

I agree, CPU0->CPU0 same core interaction is causing a bias. I could omit that
observation while computing the average.

In the verbose mode I'll omit all the threads of CPU0 and in the default
(quick) mode just CPU0's latency can be omitted while computing average.

Thank you,
Pratik

> Example, where I used the -v option for all CPUs:
>
> --IPI Latency Test---
> --Baseline IPI Latency measurement: CPU Busy--
> SRC_CPU   DEST_CPU IPI_Latency(ns)
> 0            0          101
> 0            1          790
> 0            2          609
> 0            3          595
> 0            4          737
> 0            5          759
> 0            6          780
> 0            7          741
> 0            8          574
> 0            9          681
> 0           10          527
> 0           11          552
> Baseline Avg IPI latency(ns): 620  <<<< suggest 656 here
> ---Enabling state: 0---
> SRC_CPU   DEST_CPU IPI_Latency(ns)
> 0            0           76
> 0            1          471
> 0            2          420
> 0            3          462
> 0            4          454
> 0            5          468
> 0            6          453
> 0            7          473
> 0            8          380
> 0            9          483
> 0           10          492
> 0           11          454
> Expected IPI latency(ns): 0
> Observed Avg IPI latency(ns) - State 0: 423 <<<<< suggest 456 here
> ---Enabling state: 1---
> SRC_CPU   DEST_CPU IPI_Latency(ns)
> 0            0          112
> 0            1          866
> 0            2          663
> 0            3          851
> 0            4         1090
> 0            5         1314
> 0            6         1941
> 0            7         1458
> 0            8          687
> 0            9          802
> 0           10         1041
> 0           11         1284
> Expected IPI latency(ns): 1000
> Observed Avg IPI latency(ns) - State 1: 1009 <<<< suggest 1006 here
> ---Enabling state: 2---
> SRC_CPU   DEST_CPU IPI_Latency(ns)
> 0            0           75
> 0            1        16362
> 0            2        16785
> 0            3        19650
> 0            4        17356
> 0            5        17606
> 0            6         2217
> 0            7        17958
> 0            8        17332
> 0            9        16615
> 0           10        17382
> 0           11        17423
> Expected IPI latency(ns): 120000
> Observed Avg IPI latency(ns) - State 2: 14730 <<<< suggest 17447 here
> ---Enabling state: 3---
> SRC_CPU   DEST_CPU IPI_Latency(ns)
> 0            0          103
> 0            1        17416
> 0            2        17961
> 0            3        16651
> 0            4        17867
> 0            5        17726
> 0            6         2178
> 0            7        16620
> 0            8        20951
> 0            9        16567
> 0           10        17131
> 0           11        17563
> Expected IPI latency(ns): 1034000
> Observed Avg IPI latency(ns) - State 3: 14894 <<<< suggest 17645 here
>
> Hope this helps.
>
> ... Doug


  reply	other threads:[~2021-04-09  7:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-04  8:33 [RFC v3 0/2] CPU-Idle latency selftest framework Pratik Rajesh Sampat
2021-04-04  8:33 ` [RFC v3 1/2] cpuidle: Extract IPI based and timer based wakeup latency from idle states Pratik Rajesh Sampat
2021-04-04  8:33 ` [RFC v3 2/2] selftest/cpuidle: Add support for cpuidle latency measurement Pratik Rajesh Sampat
2021-04-09  5:23 ` [RFC v3 0/2] CPU-Idle latency selftest framework Doug Smythies
2021-04-09  7:43   ` Pratik Sampat [this message]
2021-04-09 14:26     ` Doug Smythies
2023-09-11  5:36 Aboorva Devarajan
2023-09-25  5:06 ` Aboorva Devarajan
2023-10-12  4:48   ` Aboorva Devarajan

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=0a4b32e0-426e-4886-ae37-6d0bdafdea7f@linux.ibm.com \
    --to=psampat@linux.ibm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dsmythies@telus.net \
    --cc=ego@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pratik.r.sampat@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=shuah@kernel.org \
    --cc=svaidy@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).