linux-kernel - Re: [PATCH] sched: fix erroneous sysct_sched_nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 May 2011 09:18:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, Nikhil Rao <ncrao@...gle.com>,
	Mike Galbraith <efault@....de>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Stephan Barwolf <stephan.baerwolf@...ilmenau.de>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>
Subject: Re: [PATCH] sched: fix erroneous sysct_sched_nr_migrate logic

* Vladimir Davydov <vdavydov@...allels.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/