From: Rusty Russell <rusty@rustcorp.com.au>
To: Kimio Suganuma <k-suganuma@mvj.biglobe.ne.jp>
Cc: pj@engr.sgi.com, focht@ess.nec.de, rml@tech9.net,
linux-kernel@vger.kernel.org, mingo@elte.hu, colpatch@us.ibm.com,
lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] Re: [PATCH] O(1) scheduler set_cpus_allowed for non-current tasks
Date: Sat, 23 Feb 2002 13:47:43 +1100 [thread overview]
Message-ID: <20020223134743.19cb675f.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20020220173242.2BDF.K-SUGANUMA@mvj.biglobe.ne.jp>
In-Reply-To: <Pine.LNX.4.21.0202202337320.10032-100000@sx6.ess.nec.de> <Pine.SGI.4.21.0202201619560.565754-100000@sam.engr.sgi.com> <20020220173242.2BDF.K-SUGANUMA@mvj.biglobe.ne.jp>
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.
next prev parent reply other threads:[~2002-02-23 2:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-20 17:57 [PATCH] O(1) scheduler set_cpus_allowed for non-current tasks Erich Focht
2002-02-20 19:44 ` Robert Love
2002-02-20 20:38 ` [Lse-tech] " Paul Jackson
2002-02-21 0:07 ` Erich Focht
2002-02-21 1:12 ` Paul Jackson
2002-02-21 1:40 ` [Lse-tech] " Kimio Suganuma
2002-02-21 2:04 ` Paul Jackson
2002-02-21 2:29 ` Kimio Suganuma
2002-02-21 4:56 ` Reid Hekman
2002-02-23 2:47 ` Rusty Russell [this message]
2002-02-25 12:28 ` Dipankar Sarma
2002-02-26 3:59 ` Paul Jackson
2002-02-27 1:40 ` Rusty Russell
2002-02-21 14:38 ` Erich Focht
2002-02-21 16:59 ` Ingo Molnar
2002-02-21 15:15 ` Erich Focht
2002-02-21 21:05 ` Paul Jackson
2002-02-25 20:01 ` [Lse-tech] " Bill Davidsen
2002-02-21 4:49 ` [Lse-tech] " kravetz
2002-02-21 16:32 ` Ingo Molnar
2002-02-21 21:25 ` Paul Jackson
2002-02-22 9:12 ` Ingo Molnar
2002-02-22 19:44 ` [Lse-tech] " Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020223134743.19cb675f.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=colpatch@us.ibm.com \
--cc=focht@ess.nec.de \
--cc=k-suganuma@mvj.biglobe.ne.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mingo@elte.hu \
--cc=pj@engr.sgi.com \
--cc=rml@tech9.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox