From: Shrikanth Hegde <sshegde@linux.vnet.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Swapnil Sapkal <Swapnil.Sapkal@amd.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>, Aaron Lu <aaron.lu@intel.com>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 1/1] sched: Extend cpu idle state for 1ms
Date: Sat, 5 Aug 2023 21:07:18 +0530 [thread overview]
Message-ID: <c8bca664-76cf-52d7-bd73-795b467c460b@linux.vnet.ibm.com> (raw)
In-Reply-To: <df826f20-d183-98d0-78cd-d11191f97b28@efficios.com>
On 8/4/23 1:42 AM, Mathieu Desnoyers wrote:
> On 8/3/23 01:53, Swapnil Sapkal wrote:
> [...]
>
> Those are interesting metrics. I still have no clue why it behaves that
> way though.
I was thinking this might be the case. some workload would benefit while
some would suffer. Specially ones which favor latency over cache might suffer.
>
> More specifically: I also noticed that the number of migrations is
> heavily affected, and that select_task_rq behavior changes drastically.
> I'm unsure why though.
>
FWIU, load_balance uses idle_cpu to calculate the number of idle_cpus in the
sched_domain. Maybe that is getting confused with 1ms delay concept. Likely
sched_domain stay balanced because of this, and hence less migrations.
In select_rq_fair, prev_cpu will returned by wake_affine_idle since idle_cpu will return
true more often. Hence task will get woken on the same CPU as before instead of migrating.
on SMT systems, gain is further added by having the threads on single CPU, thereby
making it ST mode. That is subject to utilization. Running on ST is more faster compared
to running on SMT.
-------------------------------------------------------------------------------------------
Ran the hackbench with perf stat on SMT system. That indicates slightly higher ST mode cycles
and ips improves slightly thereby making it faster.
baseline 6.5-rc1:
hackbench -pipe (50 groups)
Time: 0.67 ( Average of 50 runs)
94,432,028,029 instructions # 0.52 insn per cycle
168,130,543,309 cycles (% of total cycles)
1,162,153,934 PM_RUN_CYC_ST_MODE ( 0.70% )
613,018,646 PM_RUN_CYC_SMT2_MODE ( 0.35% )
166,358,778,832 PM_RUN_CYC_SMT4_MODE (98.95% )
Latest patch in this series.
https://lore.kernel.org/lkml/447f756c-9c79-f801-8257-a97cc8256efe@efficios.com/#t
hackbench -pipe (50 groups)
Time: 0.62 ( Average of 50 runs)
92,078,390,150 instructions # 0.55 insn per cycle
159,368,662,574 cycles
1,330,653,107 PM_RUN_CYC_ST_MODE ( 0.83% )
656,950,636 PM_RUN_CYC_SMT2_MODE ( 0.41% )
157,384,470,123 PM_RUN_CYC_SMT4_MODE (98.75% )
>>
>> Can you share your build config just in case I am missing something.
>
> Build config attached.
>
> Thanks,
>
> Mathieu
>
>>
>>>
>>> And using it now brings the hackbench wall time at 28s :)
>>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>>
>>>>>>> struct task_struct *stop;
>>>>>>> unsigned long next_balance;
>>>>>>> struct mm_struct *prev_mm;
>>>>>
>>>
>> --
>> Thanks and regards,
>> Swapnil
>
next prev parent reply other threads:[~2023-08-05 15:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 19:30 [RFC PATCH 1/1] sched: Extend cpu idle state for 1ms Mathieu Desnoyers
2023-07-26 7:33 ` Shrikanth Hegde
2023-07-26 8:04 ` Shrikanth Hegde
2023-07-26 14:07 ` Mathieu Desnoyers
2023-07-26 17:40 ` Shrikanth Hegde
2023-07-26 18:56 ` Mathieu Desnoyers
2023-07-26 19:16 ` Mathieu Desnoyers
2023-08-01 7:24 ` Aaron Lu
2023-08-01 15:03 ` Chen Yu
2023-08-03 20:21 ` Mathieu Desnoyers
2023-08-03 5:53 ` Swapnil Sapkal
2023-08-03 20:12 ` Mathieu Desnoyers
2023-08-05 15:37 ` Shrikanth Hegde [this message]
2023-07-27 5:04 ` Chen Yu
2023-08-01 7:42 ` Aaron Lu
2023-08-04 14:04 ` David Laight
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=c8bca664-76cf-52d7-bd73-795b467c460b@linux.vnet.ibm.com \
--to=sshegde@linux.vnet.ibm.com \
--cc=Swapnil.Sapkal@amd.com \
--cc=aaron.lu@intel.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=x86@kernel.org \
/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