From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, linux-kernel@vger.kernel.org,
parth@linux.ibm.com, qais.yousef@arm.com, chris.hyser@oracle.com,
valentin.schneider@arm.com, patrick.bellasi@matbug.net,
David.Laight@aculab.com, pjt@google.com, pavel@ucw.cz,
tj@kernel.org, qperret@google.com, tim.c.chen@linux.intel.com,
joshdon@google.com, timj@gnu.org,
Gautham Shenoy <gautham.shenoy@amd.com>
Subject: Re: [PATCH v5 0/7] Add latency priority for CFS class
Date: Tue, 25 Oct 2022 12:06:24 +0530 [thread overview]
Message-ID: <89a5eeaa-4c5a-db6d-2c52-6dcb951d3a10@amd.com> (raw)
In-Reply-To: <CAKfTPtC-yMUNfnGa8a4HrT-Onf4SZfRHDKyQcDZYnzhpPOk=Xw@mail.gmail.com>
Hello Vincent,
I've rerun some tests with a different configuration with more
contention for CPU and I can see a linear behavior. Sharing the
results below.
On 10/13/2022 8:54 PM, Vincent Guittot wrote:
>
> [..snip..]
>>
>> o Hackbench and Cyclictest in NPS1 configuration
>>
>> perf bench sched messaging -p -t -l 100000 -g 16&
>> cyclictest --policy other -D 5 -q -n -H 20000
>>
>> -----------------------------------------------------------------------------------------------------------------
>> |Hackbench | Cyclictest LN = 19 | Cyclictest LN = 0 | Cyclictest LN = -20 |
>> |LN |--------------------------------|---------------------------------|-----------------------------|
>> |v | Min | Avg | Max | Min | Avg | Max | Min | Avg | Max |
>> |--------------|--------|---------|-------------|----------|---------|------------|----------|---------|--------|
>> |0 | 54.00 | 117.00 | 3021.67 | 53.67 | 65.33 | 133.00 | 53.67 | 65.00 | 201.33 | ^
>> |19 | 50.00 | 100.67 | 3099.33 | 41.00 | 64.33 | 1014.33 | 54.00 | 63.67 | 213.33 |
>> |-20 | 53.00 | 169.00 | 11661.67 | 53.67 | 217.33 | 14313.67 | 46.00 | 61.33 | 236.00 | ^
>> -----------------------------------------------------------------------------------------------------------------
>
> The latency results look good with Cyclictest LN:0 and hackbench LN:0.
> 133us max latency. This suggests that your system is not overloaded
> and cyclictest doesn't really compete with others to run.
Following is the result of running cyclictest alongside hackbench with 32 groups:
perf bench sched messaging -p -l 100000 -g 32&
cyclictest --policy other -D 5 -q -n -H 20000
----------------------------------------------------------------------------------------------------------
| Hackbench | Cyclictest LN = 19 | Cyclictest LN = 0 | Cyclictest LN = -20 |
| LN |------------------------------|-------------------------------|---------------------------|
| | Min | Avg | Max | Min | Avg | Max | Min | Avg | Max |
|-------------|--------|---------|-----------|--------|---------|------------|--------|-------|----------|
| 0 | 54.00 | 165.00 | 6899.00 | 22.00 | 85.00 | 3294.00 | 23.00 | 64.00 | 276.00 |
| 19 | 53.00 | 173.00 | 3275.00 | 40.00 | 60.00 | 2276.00 | 13.00 | 59.00 | 94.00 |
| -20 | 52.00 | 293.00 | 19980.00 | 52.00 | 280.00 | 14305.00 | 53.00 | 95.00 | 5713.00 |
----------------------------------------------------------------------------------------------------------
I see a spike for Max in (0, 0) configuration and the latency decreases
monotonically with lower latency nice value.
>
>>
>> o Hackbench and schbench in NPS1 configuration
>>
>> perf bench sched messaging -p -t -l 1000000 -g 16&
>> schebcnh -m 1 -t 64 -s 30s
>>
>> ------------------------------------------------------------------------------------------------------------
>> |Hackbench | schbench LN = 19 | schbench LN = 0 | schbench LN = -20 |
>> |LN |----------------------------|--------------------------------|-----------------------------|
>> |v | 90th | 95th | 99th | 90th | 95th | 99th | 90th | 95th | 99th |
>> |--------------|--------|--------|----------|---------|---------|------------|---------|----------|--------|
>> |0 | 4264 | 6744 | 15664 | 17952 | 32672 | 55488 | 15088 | 25312 | 50112 |
>> |19 | 288 | 613 | 2332 | 274 | 1015 | 3628 | 374 | 1394 | 4424 |
>> |-20 | 35904 | 47680 | 79744 | 87168 | 113536 | 176896 | 13008 | 21216 | 42560 | ^
>> ------------------------------------------------------------------------------------------------------------
>
> For the schbench, your test is 30 seconds long which is longer than
> the duration of perf bench sched messaging -p -t -l 1000000 -g 16&
>
> The duration of the latter varies depending of latency nice value so
> schbench is disturb more time in some cases
I've rerun this with hackbench running 128 groups alongside schbench
with 2 messenger and 1 worker each. With larger worker count, I still
see non-monotonic behavior in 99th percentile latency of schbench.
I also see number of latency samples collected by schbench to vary
over the 30 second run for different latency nice values which could
also pay a part in seeing the unexpected behavior. For lower worker
count, I see the number of samples collected is similar. Following
is the configuration and the latency reported by schbench:
perf bench sched messaging -p -t -l 150000 -g 128&
schbench -m 2 -t 1 -s 30s
Note: In all cases, hackbench runs longer than schbench.
-------------------------------------------------------------------------------------------------
| Hackbench | schbench LN = 19 | schbench LN = 0 | schbench LN = -20 |
| LN |----------------------------|---------------------------|--------------------------|
| | 90th | 95th | 99th | 90th | 95th | 99th | 90th | 95th | 99th |
|-----------|--------|--------|----------|--------|--------|---------|--------|--------|--------|
| 0 | 42 | 92 | 2972 | 26 | 49 | 2356 | 9 | 11 | 20 |
| 19 | 35 | 424 | 4984 | 13 | 390 | 5096 | 8 | 10 | 14 | ^
| -19 | 144 | 3516 | 110208 | 61 | 807 | 34880 | 25 | 39 | 295 |
-------------------------------------------------------------------------------------------------
I see 90th and 95th percentile latency decrease monotonically with
latency nice value of schbench (for a fixed latency nice value of
hackbench) but there are cases where 99th percentile latency
reported by schbench may not strictly decrease with lower latency
nice value (Marked with ^)
Note: Only a small number of bad samples can affect the 99th
percentile latency for the above configuration. The monotonic
behavior in 90th and 95th percentile latency is a good data point
to show latency nice is indeed working as expected.
If there is any specific workload you would like me to run on the
test system, or any additional data you would like for above
workloads, please do let me know.
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2022-10-25 6:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-25 14:39 Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 1/7] sched: Introduce latency-nice as a per-task attribute Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 2/7] sched/core: Propagate parent task's latency requirements to the child task Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 3/7] sched: Allow sched_{get,set}attr to change latency_nice of the task Vincent Guittot
2022-10-12 15:07 ` K Prateek Nayak
2022-10-12 15:44 ` Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 4/7] sched/fair: Take into account latency priority at wakeup Vincent Guittot
2022-10-22 15:08 ` Chen Yu
2022-10-24 22:36 ` Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 5/7] sched/fair: Add sched group latency support Vincent Guittot
2022-10-12 14:22 ` Qais Yousef
2022-10-12 15:42 ` Vincent Guittot
2022-10-12 16:07 ` Qais Yousef
2022-09-25 14:39 ` [PATCH v5 6/7] sched/core: Support latency priority with sched core Vincent Guittot
2022-09-25 14:39 ` [PATCH v5 7/7] sched/fair: Add latency list Vincent Guittot
2022-10-08 1:04 ` Youssef Esmat
2022-10-08 21:14 ` David Laight
2022-10-08 21:59 ` Steven Rostedt
2022-10-11 17:10 ` Vincent Guittot
2022-10-11 23:54 ` Youssef Esmat
2022-10-12 15:21 ` Vincent Guittot
2022-10-13 17:19 ` Youssef Esmat
2022-10-14 15:22 ` Vincent Guittot
2022-10-19 16:53 ` Vincent Guittot
2022-10-20 15:20 ` Vincent Guittot
2022-10-26 10:44 ` Dietmar Eggemann
2022-10-26 13:55 ` Vincent Guittot
2022-10-12 14:53 ` [PATCH v5 0/7] Add latency priority for CFS class K Prateek Nayak
2022-10-13 15:24 ` Vincent Guittot
2022-10-17 6:47 ` K Prateek Nayak
2022-10-25 6:36 ` K Prateek Nayak [this message]
2022-10-27 16:34 ` Vincent Guittot
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=89a5eeaa-4c5a-db6d-2c52-6dcb951d3a10@amd.com \
--to=kprateek.nayak@amd.com \
--cc=David.Laight@aculab.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=chris.hyser@oracle.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=patrick.bellasi@matbug.net \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=timj@gnu.org \
--cc=tj@kernel.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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
Powered by JetHome