From: Peter Zijlstra <peterz@infradead.org>
To: Rakib Mullick <rakib.mullick@gmail.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
paulmck <paulmck@linux.vnet.ibm.com>
Subject: Re: Add rq->nr_uninterruptible count to dest cpu's rq while CPU goes down.
Date: Thu, 16 Aug 2012 15:56:24 +0200 [thread overview]
Message-ID: <1345125384.29668.30.camel@twins> (raw)
In-Reply-To: <1345124749.31092.2.camel@localhost.localdomain>
On Thu, 2012-08-16 at 19:45 +0600, Rakib Mullick wrote:
> When a CPU is about to go down, it moves all it's sleeping task to an active CPU, then nr_uninterruptible counts are
> also moved. When moving nr_uninterruptible count, currently it chooses a randomly picked CPU from the active CPU mask
> to keep the global nr_uninterruptible count intact. But, it would be precise to move nr_uninterruptible counts to the
> CPU where all the sleeping tasks were moved and it also might have subtle impact over rq's load calculation. So, this
> patch is prepared to address this issue.
The Changelog is ill-formated. Other than that, the patch doesn't appear
to actually do what it says. The sleeping tasks can be scattered to any
number of cpus as decided by select_fallback_rq().
Furthermore there should be absolutely no impact on load calculation
what so ever. nr_uninterruptible is only ever useful as a sum over all
cpus, this total sum doesn't change regardless of where you put the
value.
Worse, there's absolutely no relation to the tasks on the runqueue
(sleeping or otherwise) and nr_uninterruptible, so coupling these
actions makes no sense what so ever.
next prev parent reply other threads:[~2012-08-16 13:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 13:45 Add rq->nr_uninterruptible count to dest cpu's rq while CPU goes down Rakib Mullick
2012-08-16 13:56 ` Peter Zijlstra [this message]
2012-08-16 14:28 ` Rakib Mullick
2012-08-16 14:42 ` Peter Zijlstra
2012-08-16 15:32 ` Rakib Mullick
2012-08-16 17:46 ` Peter Zijlstra
2012-08-17 13:39 ` Rakib Mullick
2012-08-20 9:26 ` Peter Zijlstra
2012-08-20 16:10 ` Rakib Mullick
2012-08-20 16:16 ` Peter Zijlstra
2012-08-20 16:26 ` Paul E. McKenney
2012-08-27 18:44 ` Paul E. McKenney
2012-08-28 6:57 ` Rakib Mullick
2012-08-28 13:42 ` Paul E. McKenney
2012-08-28 16:52 ` Rakib Mullick
2012-08-28 17:07 ` Paul E. McKenney
2012-08-29 1:05 ` Rakib Mullick
2012-09-04 18:43 ` [tip:sched/core] sched: Fix load avg vs cpu-hotplug tip-bot for Peter Zijlstra
2012-09-05 12:36 ` Peter Zijlstra
2012-09-05 13:29 ` Ingo Molnar
2012-09-05 17:01 ` Peter Zijlstra
2012-09-05 17:34 ` Ingo Molnar
2012-09-05 22:03 ` Peter Zijlstra
2012-09-05 23:39 ` Paul E. McKenney
2012-09-06 3:30 ` Rakib Mullick
2012-09-14 6:14 ` [tip:sched/core] sched: Fix load avg vs. cpu-hotplug tip-bot for 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=1345125384.29668.30.camel@twins \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rakib.mullick@gmail.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