Re: [RFC][PATCH] avoid cpu hot removal if busy take3

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Fri, 23 Jun 2006 12:09:50 -0700
Ashok Raj <ashok.raj@intel.com> wrote:

> On Fri, Jun 23, 2006 at 04:40:42PM +0900, KAMEZAWA Hiroyuki wrote:
> > This patch adds sysctl cpu_removal_migration.
> > If cpu_removal_migration == 1, all tasks are migrated by force.
> > If cpu_removal_migration == 0, cpu_hotremoval can fail because of not-migratable
> > tasks.
> 
> Having this dual behaviour is a concern. Probably we should have the tasks
> decide if they want to terminate themselves if its not *OK* to run on a 
> different CPU, and not have a policy in kernel decide which way the 
> behaviour should be. The kernel policy should be to always force
> the cpu removal to happen. Admin should decide what processes should terminate
> ahead of time before the removal force migrates them.
> 
Hmm..I wish this forcced migration will not break resource isolation sub system
in future.

> Once the kernel/admin chooses to perform cpu offline, it should not be possible
> for some process to veto the removal and fail the removal. Removal was probably
> choosen since we would like to offline a failing cpu, and dont want some
> thing in the way to make that happen.

But in dynamic reconfiguration case (ex. VM resiging for load balancing)
the demand is not so heavy. And if we want to remove cpu by force, just adding
one line to script, echo 1 > /proc/sys/kernel/cpu_removal_migration is enough.
This is not so big obstacle.


> > +
> > +	read_lock(&tasklist_lock);
> > +	for_each_process(p) {
> > +		if (p == current)
> > +			continue;
> > +		if (p->mm && cpus_equal(mask, p->cpus_allowed)) {
> > +			ret = 1;
> > +			pid = p->pid;
> > +			break;
> > +		}
> 
> Do you want to scan and print all possible id's? otherwise printk will
> have just 1, and next attempt will show another pid now... in case the
> admin wants to do something useful with this list, probably better to 
> give it all out?
> 
Hmm, maybe useful. I'll consider again this if I can go ahead. 

Thanks,
-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/