The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH] sched/nohz: Optimize get nohz timer target
Date: Wed, 26 Jun 2019 17:45:13 +0200	[thread overview]
Message-ID: <20190626154511.GA29951@lenoir> (raw)
In-Reply-To: <CANRm+Cw6nVOy=SZw1wrh=8+1fzOfaOZcoWBeKTa8n3UXZLik=g@mail.gmail.com>

On Wed, Jun 19, 2019 at 08:42:19AM +0800, Wanpeng Li wrote:
> Cc Frederic,
> On Tue, 18 Jun 2019 at 11:13, Wanpeng Li <kernellwp@gmail.com> wrote:
> >
> > From: Wanpeng Li <wanpengli@tencent.com>
> >
> > On a machine, cpu 0 is used for housekeeping, other 39 cpus are in
> > nohz_full mode. We can observe huge time burn in the loop for seaching
> > nearest busy housekeeper cpu by ftrace.
> >
> >   2)               |                        get_nohz_timer_target() {
> >   2)   0.240 us    |                          housekeeping_test_cpu();
> >   2)   0.458 us    |                          housekeeping_test_cpu();
> >
> >   ...
> >
> >   2)   0.292 us    |                          housekeeping_test_cpu();
> >   2)   0.240 us    |                          housekeeping_test_cpu();
> >   2)   0.227 us    |                          housekeeping_any_cpu();
> >   2) + 43.460 us   |                        }
> >
> > This patch optimizes the searching logic by finding a nearest housekeeper
> > cpu in the housekeeping cpumask, it can minimize the worst searching time
> > from ~44us to < 10us in my testing.
> >
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
> > ---
> >  kernel/sched/core.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 83bd6bb..db550cf 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -548,11 +548,12 @@ int get_nohz_timer_target(void)
> >
> >         rcu_read_lock();
> >         for_each_domain(cpu, sd) {
> > -               for_each_cpu(i, sched_domain_span(sd)) {
> > +               for_each_cpu_and(i, sched_domain_span(sd),
> > +                       housekeeping_cpumask(HK_FLAG_TIMER)) {
> >                         if (cpu == i)
> >                                 continue;
> >
> > -                       if (!idle_cpu(i) && housekeeping_cpu(i, HK_FLAG_TIMER)) {
> > +                       if (!idle_cpu(i)) {
> >                                 cpu = i;
> >                                 goto unlock;
> >                         }

Nice, but you also need to handle the default case that doesn't make much sense anymore.
It hasn't ever been clear anyway. The last iterated buzy housekeeper can become
a random candidate while current CPU is a better fallback if it is a housekeeper. Also
you're enhancing housekeeping_any_cpu() in another patch so give it a better chance:

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4778c48a7fda..c5229d71540a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -539,27 +539,32 @@ void resched_cpu(int cpu)
  */
 int get_nohz_timer_target(void)
 {
-	int i, cpu = smp_processor_id();
+	int i, cpu = smp_processor_id(), default_cpu = -1;
 	struct sched_domain *sd;
 
-	if (!idle_cpu(cpu) && housekeeping_cpu(cpu, HK_FLAG_TIMER))
-		return cpu;
+	if (housekeeping_cpu(cpu, HK_FLAG_TIMER)) {
+		if (!idle_cpu(cpu))
+			return cpu;
+		default_cpu = cpu;
+	}
 
 	rcu_read_lock();
 	for_each_domain(cpu, sd) {
-		for_each_cpu(i, sched_domain_span(sd)) {
+		for_each_cpu_and(i, sched_domain_span(sd),
+				 housekeeping_cpumask(HK_FLAG_TIMER)) {
 			if (cpu == i)
 				continue;
 
-			if (!idle_cpu(i) && housekeeping_cpu(i, HK_FLAG_TIMER)) {
+			if (!idle_cpu(i)) {
 				cpu = i;
 				goto unlock;
 			}
 		}
 	}
 
-	if (!housekeeping_cpu(cpu, HK_FLAG_TIMER))
-		cpu = housekeeping_any_cpu(HK_FLAG_TIMER);
+	if (default_cpu == -1)
+		default_cpu = housekeeping_any_cpu(HK_FLAG_TIMER);
+	cpu = default_cpu;
 unlock:
 	rcu_read_unlock();
 	return cpu;

      reply	other threads:[~2019-06-26 15:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-18  3:13 [PATCH] sched/nohz: Optimize get nohz timer target Wanpeng Li
2019-06-19  0:42 ` Wanpeng Li
2019-06-26 15:45   ` Frederic Weisbecker [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=20190626154511.GA29951@lenoir \
    --to=frederic@kernel.org \
    --cc=fweisbec@gmail.com \
    --cc=kernellwp@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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