From: Mel Gorman <mgorman@suse.de>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/fair: Make sched-idle cpu selection consistent throughout
Date: Thu, 31 Oct 2019 10:19:04 +0000 [thread overview]
Message-ID: <20191031101904.GI28938@suse.de> (raw)
In-Reply-To: <CAKohpo=hssu_uvb1J=0Od=KziAQVSMmbBt9zxa4mYttKhFJwFw@mail.gmail.com>
On Thu, Oct 31, 2019 at 02:42:03PM +0530, Viresh Kumar wrote:
> On Wed, 30 Oct 2019 at 22:17, Mel Gorman <mgorman@suse.de> wrote:
>
> > As the patch stands, I think a fork-intensive workload where each
> > process is doing small amounts of work will suffer from overloading
> > domains and have variable performance depending on how quickly the load
> > balancer reacts.
>
> Just wanted to clarify this slightly in case it is confusing. Once a
> newly forked
> (non SCHED_IDLE) task gets placed on a sched-idle CPU, it won't remain
> sched-idle anymore and we will again start looking for a fully idle CPU. So,
> we won't put everything on a small set of CPUs, but just one SCHED_NORMAL
> task on a CPU unless we are out of idle CPUs.
>
> Do you have some specific test in mind which I can run to test this ?
>
Nothing in particular. git test suite for the basic fork-intensive case
(mmtests config workload-shellscripts), something fork-intensive but
relatively short-lived like a kernel build scaling the number of build
jobs (mmtests config config-workload-kerndevel), something fairly basic
that scales number of running jobs and relatively long-lived like tbench
(mmtests config config-network-tbench). The ideal of course is that you
wrote the patch based on an observed problem that you decided to fix.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2019-10-31 10:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 6:45 [PATCH] sched/fair: Make sched-idle cpu selection consistent throughout Viresh Kumar
2019-10-25 6:43 ` Parth Shah
2019-10-25 8:11 ` Viresh Kumar
2019-10-25 12:00 ` Parth Shah
2019-10-30 16:47 ` Mel Gorman
2019-10-31 9:12 ` Viresh Kumar
2019-10-31 10:19 ` Mel Gorman [this message]
2019-11-08 11:31 ` Viresh Kumar
2019-11-08 17:01 ` 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=20191031101904.GI28938@suse.de \
--to=mgorman@suse.de \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@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.