KAMEZAWA Hiroyuki wrote:
>
> Now, cpu hot remove migrates all tasks on target cpu by force.
>
> During cpu-hot-remove, if tsk->cpus_allowed contains the only target
> cpu of removal, tsk->cpus_allowd is disposed and the kernel migrate it to
> any cpu at random. It's obvious that user-land configuration before cpu hot
> removal was bad. This looks a realisitc workaround, but this is not good in
> carefully scheduled environment.
>
> 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.
>
> Note: cpu scheduler's notifier chain has the highest priority. then, this
> failure detection will be done at first.
I'm still not convinced that this is a good thing to do. I reiterate:
this can be implemented in userspace (probably with fewer lines of
code, even). Why should this policy be in the kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
