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

[Ashok Raj]

On Fri, Jun 23, 2006 at 04:40:42PM +0900, KAMEZAWA Hiroyuki wrote:
> 
> In this case,
> 1. ignore bad configuration in user-land just do warnings.
> 2. cancel cpu hot removal and warn users to fix the problem and retry.
> seems to be a realisitc workaround. Killing the problematic process may
> cause some trouble in user-land (dead-lock etc..)
> 
> 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.

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.

> + */
> +static int test_cpu_busy(int cpu)
> +{
> +	cpumask_t mask;
> +	int ret = 0;

 Deleted....

> +
> +	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?


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