Re: [PATCH 0/10] bulk cpu removal support

[Nathan Lynch <ntl@pobox.com>]

Ashok Raj wrote:
> 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...

If the motivation for these patches is to minimize disruption of the
workload when offlining a group of cpus, then I think the reasonable
alternative is for the admin (or a script) to migrate sensitive
tasks and interrupts to cpus that are not going to be offlined --
before offlining any cpus.

On the other hand, I'm getting the feeling that the problem you're
really trying to address is that offlining lots of cpus takes a long
time (on the order of a couple seconds per cpu) on your architectures.

So is it one of these two things, or a combination of both, or what?


> 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.

I guess I don't understand what you're getting at here.  Are you
agreeing with me?  Or are you saying that doing this is a problem?


> 2. For interrrupt migration, today when we take a cpu offline, we pick 
> a random online cpu today.

That's an architecture-specific behavior.  On powerpc, interrupts
bound to a dying cpu have their affinity reset to the default (all cpus).


> 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.

Yes, and the kernel really shouldn't have to be smart about this.
This is a matter of policy.  The admin knows which cpus are going to
be online.  The admin is free to reassign the irqs before offlining
cpus for optimal behavior.  (Of course, the kernel should still have a
sane fallback behavior, and it does.)

So, I still don't see the benefit of adding this change which works
around the kernel's scheduling behavior etc. when the admin easily has
the ability to mitigate the disruption by taking some preliminary
measures.