On 17/10/12 21:59, Gilles Chanteperdrix wrote:
>
> When you do:
>
> CPU_SET(1,&cpuset);
> sched_setaffinity(0, sizeof(cpuset),&cpuset);
> rt_task_shadow(&task, "test", 99, 0);
>
> then rt_task_shadow will migrate the thread from cpu 1 to cpu 0,
> so it migrates twice overall (assuming Linux had started it on cpu 0).
>
> When you do:
>
> rt_task_shadow(&task, "test", 99, 0);
> CPU_SET(1,&cpuset);
> sched_setaffinity(0, sizeof(cpuset),&cpuset);
>
> then sched_setaffinity will migrate the thread from cpu 0 to cpu 1.
>
> My point was that it seems inconsistent that it makes a difference
> in which order you shadow the task and you specify which cpu it should
> run on.
Yes, I got it, we need to fix that too.
On second thought, it actually makes more sense if the xenomai nucleus would
keep the thread on the CPU it is currently assigned to (unless the affinity
specifies something else). In fact, I thought this was already the case...
And I can see code in xnpod_start_thread which does exactly that. So why does
the first example migrate the task to a different CPU?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
