Xenomai thread migration

Xenomai中的任务需要通过以下方式显示声明CPU迁移，　否则系统不会主动进行迁移。

原因是迁移本身会带来延迟，系统决定不去做迁移的判断。

参考：

http://www.xenomai.org/pipermail/xenomai/2013-September/029248.html

> Or is there a complex algorithm to determine who is in a processor in a
> instance ?

No complex algorithm at all. A Xenomai thread is given a static affinity
when it emerges, based on the one linux chose when cloning the new task.
Then the Xenomai app may chose to change that affinity, using the
relevant API calls (i.e. sched_setaffinity for the POSIX one). Xenomai
will notice and maintain consistency between schedulers.

At any rate, Xenomai deliberately refrains from doing any dynamic load
balancing over CPUs, because this is a latency killer (resuming from a
cold cache, cost of the migration process and so on). If a Xenomai
thread wants to move to another CPU, it has to request it explicitly.
We don't know how to do CPU migration efficiently wrt latency, so we
don't do it, and accept dumbness.

http://comments.gmane.org/gmane.linux.real-time.xenomai.devel/1903

> Or we can get rid of xnpod_migrate_thread(), it is currently not used by
> any skin.
> 

It's a fundamental feature for placing SMP jobs, and kernel-based
Xenomai threads could not rely on sched_setscheduler() to do it. Let's
keep this service, and simply pass the sched pointer to the accumulation
routine; I was wrong initially suggesting the opposite. IOW, let's avoid
smashing a squadron of flies with nukes...