lkml.org 
[lkml]   [2006]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] avoid cpu hot removal if busy take3
On Fri, 23 Jun 2006 12:09:50 -0700 Ashok Raj wrote:

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

You are making a value call as you see it. Others have
disagreed.

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

Just how slowly or quickly to CPUs fail? Does an admin have time
to look up the list of processes that are bound to which CPUs,
move them or kill them, etc., before giving the offline-that-CPU
command? or would she/he rather tell the system how to handle
CPU-offlining conflicts and then just issue the one command?


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

Yep, I noticed that too, but didn't comment on it.

---
~Randy
-
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/

\
 
 \ /
  Last update: 2006-06-25 00:21    [W:0.058 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site