Backport of affinity patch to RTT v1

Submitted by snrkiwi on Sun, 2011-06-12 17:40

Backport of the RTT v2 affinity patch to v1, along with updates (I have already put a merge request in on gitorious for these in RTT v2).

A couple of questions (the first two apply to RTT v2 also)

- what shall we do about the current limit of 32-CPU machines (at least that's the type size on my 32-bit Ubuntu). We already have 24-CPU machines at work ... it's only a matter of time ...

- why is the return value when setting the affinity not propogated out of gnulinux's rtos_task_create()?

- should the affinity func's be down in ThreadInterface?

All tests pass on Snow Leopard, and on Lucid Lynx (1, 2 and 8 CPU VMs tested)

And wow, is the v1 API more torturous than v2. Some of the classes have the same parametres in the constructor, but the order differs between classes. Not cool ... easy to get caught ... :-(
S

AttachmentSize
0003-tests-Add-CPU-affinity-test-for-Linux-only.patch3.45 KB
0002-gnulinux-Correct-use-of-CPU-mask.-Log-on-failure-to-.patch1.77 KB
0001-Backport-CPU-affinity-feature-from-v2.patch47.38 KB
‹ [Bug 865] New: [PATCH] TimerComponent: replace single port for all timers with a separate port for each timer Removing the "undefined symbols in libraries" check from autoproj ›
»

Backport of affinity patch to RTT v1

Submitted by peter on Fri, 2011-07-15 16:32.

On Sunday 12 June 2011 19:35:33 S Roderick wrote:
> Backport of the RTT v2 affinity patch to v1, along with updates (I have
> already put a merge request in on gitorious for these in RTT v2).

Thanks, I've put them on the 1.x trunk.

>
> A couple of questions (the first two apply to RTT v2 also)
>
> - what shall we do about the current limit of 32-CPU machines (at least
> that's the type size on my 32-bit Ubuntu). We already have 24-CPU machines
> at work ... it's only a matter of time ...

Someone will have to invent an additional API to cover these cases :-)

>
> - why is the return value when setting the affinity not propogated out of
> gnulinux's rtos_task_create()?

I think the question here is if a wrong affinity should cancel the thread's
creation... The current implementations fall back to 'any cpu' if it fails.

>
> - should the affinity func's be down in ThreadInterface?

It should, and setCPUAffinity() is already a virtual...

>
> All tests pass on Snow Leopard, and on Lucid Lynx (1, 2 and 8 CPU VMs
> tested)
>
> And wow, is the v1 API more torturous than v2. Some of the classes have the
> same parametres in the constructor, but the order differs between classes.
> Not cool ... easy to get caught ... :-( S

We fixed this indeed in v2 (at least we discussed about it how to fix it best).

Peter

»