Improved idea, to use NR_CPUS task_migrators for SMPs.

[J.C. Pizarro]

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?

   ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/