From: Ingo Molnar <mingo@elte.hu>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, Nikhil Rao <ncrao@google.com>,
Mike Galbraith <efault@gmx.de>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Stephan Barwolf <stephan.baerwolf@tu-ilmenau.de>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>
Subject: Re: [PATCH] sched: fix erroneous sysct_sched_nr_migrate logic
Date: Fri, 6 May 2011 09:18:30 +0200 [thread overview]
Message-ID: <20110506071830.GD23166@elte.hu> (raw)
In-Reply-To: <1304536548-3052-1-git-send-email-vdavydov@parallels.com>
* Vladimir Davydov <vdavydov@parallels.com> wrote:
> During load balance, the scheduler must not iterate more than
> sysctl_sched_nr_migrate (32 by default) tasks, but at present this limit is held
> only for tasks in a task group. That means if there is the only task group in
> the system, the scheduler never iterates more than 32 tasks in a single balance
> run, but if there are N task groups, it can iterate up to N * 32 tasks. This
> patch makes the limit system-wide as it should be.
> ---
> kernel/sched_fair.c | 35 +++++++++++++++++------------------
> 1 files changed, 17 insertions(+), 18 deletions(-)
Well, you are right that we currently scale "nr_groups*32", but changing this
will have an effect on default scheduling behavior, especially if there are a
lot of groups.
So either it has to be shown (measured, demonstrated) that the current behavior
is catastrophic or clearly bad in some workloads, or it has to be shown
(measured) that it has no bad effect on the balancing quality of workloads
involving a lot of groups.
What was the motivation for the patch - have you noticed it via review, or have
you run into a workload that demonstrated it? Such details need to be in
changelogs.
If there's adverse effect on balancing quality we might still do something
about the number of iterations, but it all has to be done a lot more carefully
than just capping it to 32 globally, without any numbers and analysis ...
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-06 7:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 19:15 [PATCH] sched: fix erroneous sysct_sched_nr_migrate logic Vladimir Davydov
2011-05-06 7:18 ` Ingo Molnar [this message]
[not found] ` <9532E773-BD05-4A18-B9BD-6B667F15FF91@parallels.com>
2011-05-10 9:10 ` Peter Zijlstra
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=20110506071830.GD23166@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ncrao@google.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=stephan.baerwolf@tu-ilmenau.de \
--cc=vatsa@linux.vnet.ibm.com \
--cc=vdavydov@parallels.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