On Wed, 20 Feb 2002 17:40:56 -0800
Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp> wrote:
> Hi all,
>
> On Wed, 20 Feb 2002 17:12:21 -0800
> Paul Jackson <pj@engr.sgi.com> wrote:
>
> > > Another problem is the right moment to change the cpu field of the
> > > task. ... The IPI to the target CPU is the same as in the
> > > initial design of Ingo. It has to wait for the task to unschedule and
> > > knows it will find it dequeued.
> >
> > How about not changing anything of the target task synchronously,
> > except for some new "proposed_cpus_allowed" field. Set that
> > field and get out of there. Let the target process run the
> > set_cpus_allowed() routine on itself, next time it passes through
> > the schedule() code. Leave it the case that the set_cpus_allowed()
> > routine can only be run on the current process.
> >
> > Perhaps others need this cpus_allowed change (and the migration
> > of a task to a different allowed cpu) to happen "right away".
> > But I don't, and I don't (yet) know that anyone else does.
>
> CPU hotplug needs to change cpus_allowed in definite time.
> When a process is sleeping for 100000 seconds, how can we offline
> a CPU the process belongs?
Hi All,
I've been working on hotplug with the new scheduler and preempt.
It still crashes, so no public code yet 8). It follows Linus's suggestion
that cpu_up() be called during the boot process, which is nicer.
But this particular problem did not hurt me, since I now run a
"suicide" thread on the dying CPU, making it safe and trivial to manually
re-queue processes. The question of what to do with processes which cannot
be scheduled on any remaining CPUs is another interesting question.
(Note: downing a CPU with a suicide thread introduces cleanup issues: I may
yet return to the original implementations where suicide thread == idle thread).
Hope that helps,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:48 EST