* Improved idea, to use NR_CPUS task_migrators for SMPs.
@ 2008-02-22 22:57 J.C. Pizarro
2008-02-22 23:57 ` J.C. Pizarro
0 siblings, 1 reply; 2+ messages in thread
From: J.C. Pizarro @ 2008-02-22 22:57 UTC (permalink / raw)
To: LKML
In kernel/sched.c appears:
static void sched_migrate_task(struct task_struct *p, int dest_cpu)
{
struct migration_req req;
unsigned long flags;
struct rq *rq;
rq = task_rq_lock(p, &flags);
if (!cpu_isset(dest_cpu, p->cpus_allowed)
|| unlikely(cpu_is_offline(dest_cpu)))
goto out;
/* force the process onto the specified CPU */
if (migrate_task(p, dest_cpu, &req)) {
/* Need to wait for migration thread (might exit: take ref). */
struct task_struct *mt = rq->migration_thread;
get_task_struct(mt);
task_rq_unlock(rq, &flags); <---- comment #1
wake_up_process(mt); <---- comment #2
put_task_struct(mt);
wait_for_completion(&req.done); <---- comment #3
<---- comment #4
return;
}
out:
task_rq_unlock(rq, &flags);
}
--------------------
* comment #1: why unlock soon this insecure task when it's still incomplete
and preemptible? IMHO, one of the reasons is that this task needs be unlocked
to be manipulated by this code, otherwise it could be deadlocked. But it's not
a good silver bullet.
* comment #2: why wake slowing its migration thread? what is the matter
if the picked task is SUSPENDED, BLOCKED, SIGSTOPed, KILLED or ZOMBIED?
It can ocurr "not running as expected". It's not a good decision.
* comment #3: what ocurrs it if the waiting is eternal as said comment #2
or as be deadlocked preemptibly? Arggghhhh!
I thought that it's better to implement NR_CPUS task_migrators as kernel's
threads-daemons with lockers's mechanisms. For comprension, unlocking
some lockers of the task_migrators and inmediately switching CPU to
migrators is similar to quick awakening of migration_thread.
The being-migrated task "doesn't must know the #cpu that this task is
being runned", and IMHO it's little complicated when the task has
lockers, signals, etc
that depends from #cpu (lockers and more things need be altered when they
are migrated, overall their identifiers).
* comment #4: when sleep the migration thread?
;)
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Improved idea, to use NR_CPUS task_migrators for SMPs.
2008-02-22 22:57 Improved idea, to use NR_CPUS task_migrators for SMPs J.C. Pizarro
@ 2008-02-22 23:57 ` J.C. Pizarro
0 siblings, 0 replies; 2+ messages in thread
From: J.C. Pizarro @ 2008-02-22 23:57 UTC (permalink / raw)
To: LKML
On 2008/2/22, J.C. Pizarro <jcpiza@gmail.com>, i wrote:
> For comprension, unlocking
> some lockers of the task_migrators and inmediately switching CPU to
> migrators is similar to quick awakening of migration_thread.
I'm sorry, it's wrong, the correct is in reverse, locking when it wants to enter
and unlocking when it's exited.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-02-22 23:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-22 22:57 Improved idea, to use NR_CPUS task_migrators for SMPs J.C. Pizarro
2008-02-22 23:57 ` J.C. Pizarro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®