From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Vladimir Davydov <VDavydov@parallels.com>
Cc: Ingo Molnar <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <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: Tue, 10 May 2011 11:10:38 +0200 [thread overview]
Message-ID: <1305018638.2914.35.camel@laptop> (raw)
In-Reply-To: <9532E773-BD05-4A18-B9BD-6B667F15FF91@parallels.com>
On Fri, 2011-05-06 at 14:02 +0400, Vladimir Davydov wrote:
>
> But looking through the code, I found the definition:
>
> /* * Number of tasks to iterate in a single balance run. * Limited
> because this is done with IRQs disabled. */ const_debug unsigned int
> sysctl_sched_nr_migrate = 32;
>
> However, AFAIS from the code, the number of tasks to iterate is
> virtually unlimited. So I conclude either the comment is confusing, or
> the logic is wrong.
>
Right, so I mostly agree with your (haven't actually read your patch
yet), the one worry I have is that we'll get stuck endlessly trying to
balance the first cgroup and when there's enough tasks in there but not
enough weight, we'll get stuck not making much progress.
This is one of the many things with the whole cgroup mess that needs
proper sorting out.
So yes, I agree with your interpretation of the sysctl, but I don't
think a straight fwd accounting 'fix' will actually result in a better
kernel.
prev parent reply other threads:[~2011-05-10 9:07 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
[not found] ` <9532E773-BD05-4A18-B9BD-6B667F15FF91@parallels.com>
2011-05-10 9:10 ` Peter Zijlstra [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=1305018638.2914.35.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=VDavydov@parallels.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ncrao@google.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=stephan.baerwolf@tu-ilmenau.de \
--cc=vatsa@linux.vnet.ibm.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