From: Ashok Raj <ashok.raj@intel.com>
To: Nathan Lynch <ntl@pobox.com>
Cc: Ashok Raj <ashok.raj@intel.com>, Andrew Morton <akpm@osdl.org>,
Shaohua Li <shaohua.li@intel.com>,
linux-kernel@vger.kernel.org, zwane@linuxpower.ca,
vatsa@in.ibm.com
Subject: Re: [PATCH 0/10] bulk cpu removal support
Date: Thu, 11 May 2006 10:40:30 -0700 [thread overview]
Message-ID: <20060511104030.A15782@unix-os.sc.intel.com> (raw)
In-Reply-To: <20060511171920.GB10833@localdomain>; from ntl@pobox.com on Thu, May 11, 2006 at 12:19:20PM -0500
On Thu, May 11, 2006 at 12:19:20PM -0500, Nathan Lynch wrote:
>
> But offlining all the cpus in a node is already something that just
> works. If the user is all that concerned about not thrashing the
> tasks running on that node, they would have a workload manager that
> migrates the tasks off the node before shooting down cpus. Similar
> argument applies to interrupt affinity.
>
> I really haven't seen a compelling argument for why this is needed,
> just a bunch of handwaving so far, sorry.
Hand waving? Dont think that was intensional though.. i think we are trying
to address a real problem, if there is a reasonable alternate already
that we are not aware of, no problemo...
1. Regarding process migration, someone needs to make sure they run
something like a taskset away from all the cpus that are planned to be
removed upfront. This needs to be done on all processes on the system.
[nick, is there an easier way to do this in today's sched infrastructure or
otherwise]
2. For interrrupt migration, today when we take a cpu offline, we pick
a random online cpu today. So if you have a cpu going offline, and the
next logical cpu is also part of the same package, or node, we have
no smarts today to keep migration away from those "to be offlined" cpus.
If we have a solution to these already, or a simpler alternative, we are
open to those... and iam getting help on large system validation.. it might
not be easy right away, but its comming.
Cheers,
ashok
--
Cheers,
Ashok Raj
- Open Source Technology Center
next prev parent reply other threads:[~2006-05-11 17:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-08 5:45 [PATCH 0/10] bulk cpu removal support Shaohua Li
2006-05-08 6:29 ` Nathan Lynch
2006-05-08 7:39 ` Shaohua Li
2006-05-08 6:30 ` Ashok Raj
2006-05-11 6:06 ` Andrew Morton
2006-05-11 16:53 ` Ashok Raj
2006-05-11 17:02 ` Andrew Morton
2006-05-11 17:27 ` Ashok Raj
2006-05-11 20:42 ` Martin Bligh
2006-05-11 22:09 ` Ashok Raj
2006-05-12 0:04 ` Nathan Lynch
2006-05-11 17:19 ` Nathan Lynch
2006-05-11 17:40 ` Ashok Raj [this message]
2006-05-11 19:19 ` Nathan Lynch
2006-05-11 22:17 ` Ashok Raj
-- strict thread matches above, loose matches on Subject: below --
2006-05-14 20:49 Protasevich, Natalie
2006-05-14 21:28 Protasevich, Natalie
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=20060511104030.A15782@unix-os.sc.intel.com \
--to=ashok.raj@intel.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntl@pobox.com \
--cc=shaohua.li@intel.com \
--cc=vatsa@in.ibm.com \
--cc=zwane@linuxpower.ca \
/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.