From: Pratik Sampat <psampat@linux.ibm.com>
To: ego@linux.vnet.ibm.com
Cc: rjw@rjwysocki.net, daniel.lezcano@linaro.org, mpe@ellerman.id.au,
benh@kernel.crashing.org, paulus@samba.org,
srivatsa@csail.mit.edu, shuah@kernel.org, npiggin@gmail.com,
svaidy@linux.ibm.com, linux-pm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 2/2] selftest/cpuidle: Add support for cpuidle latency measurement
Date: Tue, 21 Jul 2020 17:26:49 +0530 [thread overview]
Message-ID: <9465ac64-1f24-fea5-6c57-59cce00a2ba8@linux.ibm.com> (raw)
In-Reply-To: <20200720055242.GB31497@in.ibm.com>
Hi Gautham, Thanks for the review.
On 20/07/20 11:22 am, Gautham R Shenoy wrote:
> Hi Pratik,
>
>
> On Fri, Jul 17, 2020 at 02:48:01PM +0530, Pratik Rajesh Sampat wrote:
>> This patch adds support to trace IPI based and timer based wakeup
>> latency from idle states
>>
>> Latches onto the test-cpuidle_latency kernel module using the debugfs
>> interface to send IPIs or schedule a timer based event, which in-turn
>> populates the debugfs with the latency measurements.
>>
>> Currently for the IPI and timer tests; first disable all idle states
>> and then test for latency measurements incrementally enabling each state
>>
>> Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
> A few comments below.
>
>> ---
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/cpuidle/Makefile | 6 +
>> tools/testing/selftests/cpuidle/cpuidle.sh | 257 +++++++++++++++++++++
>> tools/testing/selftests/cpuidle/settings | 1 +
>> 4 files changed, 265 insertions(+)
>> create mode 100644 tools/testing/selftests/cpuidle/Makefile
>> create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh
>> create mode 100644 tools/testing/selftests/cpuidle/settings
>>
> [..skip..]
>
>> +
>> +ins_mod()
>> +{
>> + if [ ! -f "$MODULE" ]; then
>> + printf "$MODULE module does not exist. Exitting\n"
> If the module has been compiled into the kernel (due to a
> localyesconfig, for instance), then it is unlikely that we will find
> it in /lib/modules. Perhaps you want to check if the debugfs
> directories created by the module exist, and if so, print a message
> saying that the modules is already loaded or some such?
>
That's a good idea. I can can grep for this module within /proc/modules
and not insert it, if it is already there
>> + exit $ksft_skip
>> + fi
>> + printf "Inserting $MODULE module\n\n"
>> + insmod $MODULE
>> + if [ $? != 0 ]; then
>> + printf "Insmod $MODULE failed\n"
>> + exit $ksft_skip
>> + fi
>> +}
>> +
>> +compute_average()
>> +{
>> + arr=("$@")
>> + sum=0
>> + size=${#arr[@]}
>> + for i in "${arr[@]}"
>> + do
>> + sum=$((sum + i))
>> + done
>> + avg=$((sum/size))
> It would be good to assert that "size" isn't 0 here.
Sure
>> +}
>> +
>> +# Disable all stop states
>> +disable_idle()
>> +{
>> + for ((cpu=0; cpu<NUM_CPUS; cpu++))
>> + do
>> + for ((state=0; state<NUM_STATES; state++))
>> + do
>> + echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> So, on offlined CPUs, we won't see
> /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state directory. You
> should probably perform this operation only on online CPUs.
Right. I should make CPU operations only on online CPUs all over the script
[..snip..]
Thanks
Pratik
prev parent reply other threads:[~2020-07-21 11:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 9:17 [PATCH v2 0/2] Selftest for cpuidle latency measurement Pratik Rajesh Sampat
2020-07-17 9:18 ` [PATCH v2 1/2] cpuidle: Trace IPI based and timer based wakeup latency from idle states Pratik Rajesh Sampat
2020-07-20 5:00 ` Gautham R Shenoy
2020-07-17 9:18 ` [PATCH v2 2/2] selftest/cpuidle: Add support for cpuidle latency measurement Pratik Rajesh Sampat
2020-07-20 5:52 ` Gautham R Shenoy
2020-07-21 11:56 ` Pratik Sampat [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=9465ac64-1f24-fea5-6c57-59cce00a2ba8@linux.ibm.com \
--to=psampat@linux.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=daniel.lezcano@linaro.org \
--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=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=rjw@rjwysocki.net \
--cc=shuah@kernel.org \
--cc=srivatsa@csail.mit.edu \
--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).