http://bugs.orocos.org/show_bug.cgi?id=853

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

http://bugs.orocos.org/show_bug.cgi?id=853

--- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-05 15:35:03 CEST ---
(In reply to comment #4)
> Created attachment 682 [details]
> Add cpu affinity feature to ocl.

We can't change the API of setActivity()/setPeriodicActivity() in the deployer.
This would break tons of applications, which don't provide the extra parameter.

What we can allow is the extra XML tag, since it's optional. Users can still
use the setCPUAffinity() operation of the TC in order to manipulate it after
creation.

But most of this patch won't work.

Peter

http://bugs.orocos.org/show_bug.cgi?id=853

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...

--- Comment #5 from Peter Soetens <peter [..] ...> 2011-05-05 15:29:25 CEST ---
(In reply to comment #3)
> > Different cpu-mask would imply different thread, imo.
>
> OK
>
> >I think you should document a bit better how the CPU mask is interpreted, and
> >it would be advisable to typedef a oro_cpu_mask_t in the fosi.h which depends
> >on the target. We did so with most target specific types.
>
> I have documented the cpu_affinity in os/fosi_internal_interface.hpp. In
> Thread.hpp and other places where we use the cpu_affinity, i make a reference
> to this doc.
> I think we don't need to make a typedef. The cpu_affinity is an os independant
> mask. Each os/xxx/fosi_internal.cpp interpret this mask for os specific
> implementation. In my patch, i don't directly use the cpu_affinity for calling
> set_sched_affinity. I decompose the mask.

I prefer to explicitly explain the meaning of the cpu_affinity. You only got 32
bits so evidently, each bit can only stand for one CPU. I can see a problem
coming in some time (my system has 12 cpus already), but I'm not going to
torment you about that...

>
>
> >Also, your patch breaks all the other targets, so at least extending their
> >fosi function signatures to take the extra argument is necessary, ie, extend
> >rtos_task_create and let them have an empty rtos_task_set/get_cpu_affinity
>
> OK, i have fixed this issue.
>
> >Finally, I'm a bit uneasy with modifying os::Thread's constructor, although it
> >is allowed-if-good-reason since it's not in the RTT namespace.
>
> What do you suggest for introducing this new feature ? I think that it is a
> good reason.
>
>
> I have updated the patch.

It looks fine to me.

Peter

http://bugs.orocos.org/show_bug.cgi?id=853

Chavent Paul <paul [dot] chavent [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #682|Add cpu affinity to ocl. |Add cpu affinity feature to
description| |ocl.

http://bugs.orocos.org/show_bug.cgi?id=853

Chavent Paul <paul [dot] chavent [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #682|Add the cpu affinity |Add cpu affinity to ocl.
description|feature to the deployer. |

http://bugs.orocos.org/show_bug.cgi?id=853

Chavent Paul <paul [dot] chavent [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #681|New patch. |Add cpu affinity feature to
description| |rtt.

http://bugs.orocos.org/show_bug.cgi?id=853

--- Comment #4 from Chavent Paul <paul [dot] chavent [..] ...> 2011-05-02 17:17:15 CEST ---
Created attachment 682
--> http://bugs.orocos.org/attachment.cgi?id=682
Add the cpu affinity feature to the deployer.

http://bugs.orocos.org/show_bug.cgi?id=853

--- Comment #3 from Chavent Paul <paul [dot] chavent [..] ...> 2011-05-02 17:01:29 CEST ---

> Different cpu-mask would imply different thread, imo.

OK

>I think you should document a bit better how the CPU mask is interpreted, and
>it would be advisable to typedef a oro_cpu_mask_t in the fosi.h which depends
>on the target. We did so with most target specific types.

I have documented the cpu_affinity in os/fosi_internal_interface.hpp. In
Thread.hpp and other places where we use the cpu_affinity, i make a reference
to this doc.
I think we don't need to make a typedef. The cpu_affinity is an os independant
mask. Each os/xxx/fosi_internal.cpp interpret this mask for os specific
implementation. In my patch, i don't directly use the cpu_affinity for calling
set_sched_affinity. I decompose the mask.

>Also, your patch breaks all the other targets, so at least extending their
>fosi function signatures to take the extra argument is necessary, ie, extend
>rtos_task_create and let them have an empty rtos_task_set/get_cpu_affinity

OK, i have fixed this issue.

>Finally, I'm a bit uneasy with modifying os::Thread's constructor, although it
>is allowed-if-good-reason since it's not in the RTT namespace.

What do you suggest for introducing this new feature ? I think that it is a
good reason.

I have updated the patch.

http://bugs.orocos.org/show_bug.cgi?id=853

Chavent Paul <paul [dot] chavent [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #675 is|0 |1
obsolete| |

--- Comment #2 from Chavent Paul <paul [dot] chavent [..] ...> 2011-05-02 17:00:18 CEST ---
Created attachment 681
--> http://bugs.orocos.org/attachment.cgi?id=681
New patch.

http://bugs.orocos.org/show_bug.cgi?id=853

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Target Milestone|--- |next-major

--- Comment #1 from Peter Soetens <peter [..] ...> 2011-04-22 12:45:05 CEST ---
(In reply to comment #0)
> Created attachment 675
> Add cpu affinity feature.
>
> I would like to try some test by "shielding" cpus.
>
> I suggest this patch that purpose an example of how it could be done for the
> gnulinux OS.
>
> I'am currently testing this patch and some feedback would be welcome.
>
> And the most important : are you interested to include this feature ?

It is a long requested feature... I'll see if it can be included in 2.4.0...

Peter