All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Rik van Riel <riel@surriel.com>, Mel Gorman <mgorman@suse.de>,
	linux-kernel@vger.kernel.org,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] sched/fair: Call newidle_balance() from finish_task_switch()
Date: Wed, 29 Apr 2020 13:00:58 +0100	[thread overview]
Message-ID: <jhjtv12pklx.mognet@arm.com> (raw)
In-Reply-To: <2a30101cc0adb63ee7ce7b32119579d78de24b71.camel@redhat.com>


On 28/04/20 23:33, Scott Wood wrote:
> On Tue, 2020-04-28 at 22:37 +0100, Valentin Schneider wrote:
>> On 28/04/20 06:02, Scott Wood wrote:
>> > Thus, newidle_balance() is entered with interrupts enabled, which allows
>> > (in the next patch) enabling interrupts when the lock is dropped.
>> >
>> > Signed-off-by: Scott Wood <swood@redhat.com>
>> > ---
>> >  kernel/sched/core.c  |  7 ++++---
>> >  kernel/sched/fair.c  | 45 ++++++++++++++++----------------------------
>> >  kernel/sched/sched.h |  6 ++----
>> >  3 files changed, 22 insertions(+), 36 deletions(-)
>> >
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index 9a2fbf98fd6f..0294beb8d16c 100644
>> > --- a/kernel/sched/core.c
>> > +++ b/kernel/sched/core.c
>> > @@ -3241,6 +3241,10 @@ static struct rq *finish_task_switch(struct
>> > task_struct *prev)
>> >       }
>> >
>> >       tick_nohz_task_switch();
>> > +
>> > +	if (is_idle_task(current))
>> > +		newidle_balance();
>> > +
>>
>> This means we must go through a switch_to(idle) before figuring out we
>> could've switched to a CFS task, and do it then. I'm curious to see the
>> performance impact of that.
>
> Any particular benchmark I should try?
>

I'm going to be very original and suggest hackbench :-)

That would just be the first stop however, you would also want to try
something less wakeup-intensive, maybe sysbench and the like - I'm thinking
if you spawn ~1.5*nr_cpu_ids CPU-hogs, you'll hit that double switch fairly
easily.

And then there's always the big boys benchmarks like specjbb and co - I'd
suggest having a look at Mel's mmtests.

  reply	other threads:[~2020-04-29 12:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  5:02 [RFC PATCH 0/3] newidle_balance() latency mitigation Scott Wood
2020-04-28  5:02 ` [RFC PATCH 1/3] sched/fair: Call newidle_balance() from finish_task_switch() Scott Wood
2020-04-28 21:37   ` Valentin Schneider
2020-04-28 22:09     ` Peter Zijlstra
2020-04-28 22:55       ` Scott Wood
2020-04-28 23:02         ` Peter Zijlstra
2020-04-28 23:20           ` Scott Wood
2020-04-29  9:05             ` Peter Zijlstra
2020-04-30  1:31               ` Scott Wood
2020-05-11 10:58                 ` Peter Zijlstra
2020-05-11 12:13                   ` Peter Zijlstra
2020-04-28 22:33     ` Scott Wood
2020-04-29 12:00       ` Valentin Schneider [this message]
2020-04-29  8:27   ` Vincent Guittot
2020-04-30  1:36     ` Scott Wood
2020-04-28  5:02 ` [RFC PATCH 2/3] sched/fair: Enable interrupts when dropping lock in newidle_balance() Scott Wood
2020-04-28  5:02 ` [RFC PATCH 3/3] sched,rt: break out of load balancing if an RT task appears Scott Wood
2020-04-28 14:28   ` [RFC PATCH 3/3] sched, rt: " kbuild test robot
2020-04-28 21:56   ` [RFC PATCH 3/3] sched,rt: " Valentin Schneider
2020-04-28 22:33     ` Scott Wood
2020-04-28 22:52       ` Scott Wood
2020-04-29 12:01       ` Valentin Schneider
2020-04-28 13:27 ` [RFC PATCH 0/3] newidle_balance() latency mitigation Steven Rostedt
2020-04-29 23:13 ` Valentin Schneider
2020-04-30  7:44   ` Vincent Guittot
2020-04-30 10:14     ` Valentin Schneider
2020-04-30 12:42       ` Vincent Guittot
2020-04-30 13:56         ` Valentin Schneider
2020-04-30 12:48 ` 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=jhjtv12pklx.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=rostedt@goodmis.org \
    --cc=swood@redhat.com \
    --cc=vincent.guittot@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.