Thread affinity cpu core

Hello,


I am trying to set the thread affinity in a little project of mine and I am a little confuse. I don't think that's possible to link a thread with a specific core with Mac OS X, which really surprise me. It seems that you can only give int to the os to sort your thread, but does it mean the thread will be executed on the same core for all the application execution?

To test, I've wrote a simple program to validate and it seems impossible to print from which core the thread is executing. For example, on linux, you can use sched_getcpu() function to get the cpu id.


To set the affinity on my thread, I did something like that:

thread_affinity_policy_data_t policy = { m_affinityMask };
thread_policy_set(pthread_mach_thread_np(m_thread.native_handle()), THREAD_AFFINITY_POLICY, (thread_policy_t)&policy, 1);


In this case, I imaginge the term affinity mask is wrong since it's more like an abstract tag. Can you give me advice on this?


Thanks!

Up vote post of Hugo Elmoznino Down vote post of Hugo Elmoznino
5.4k views
Posted by
Hugo Elmoznino
Reply
Add a Comment

Accepted Reply

I don't think that's possible to link a thread with a specific core with Mac OS X …

That’s correct.

To test, I've wrote a simple program to validate and it seems impossible to print from which core the thread is executing.

That’s also correct.

Well, there are ways to work this out but the previous point means it doesn’t do you any good (by the time you look at the result, you might be running on a different CPU).

With regards 

THREAD_AFFINITY_POLICY
, that seems pretty well covered in the header comments within 
<Kernel/thread_policy.h>
. To wit: 
This policy is experimental.

This may be used to express affinity relationships between threads in
the task. Threads with the same affinity tag will be scheduled to
share an L2 cache if possible. That is, affinity tags are a hint to
the scheduler for thread placement.

The namespace of affinity tags is generally local to one task.
However, a child task created after the assignment of affinity tags by
its parent will share that namespace. In particular, a family of
forked processes may be created with a shared affinity namespace.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

I don't think that's possible to link a thread with a specific core with Mac OS X …

That’s correct.

To test, I've wrote a simple program to validate and it seems impossible to print from which core the thread is executing.

That’s also correct.

Well, there are ways to work this out but the previous point means it doesn’t do you any good (by the time you look at the result, you might be running on a different CPU).

With regards 

THREAD_AFFINITY_POLICY
, that seems pretty well covered in the header comments within 
<Kernel/thread_policy.h>
. To wit: 
This policy is experimental.

This may be used to express affinity relationships between threads in
the task. Threads with the same affinity tag will be scheduled to
share an L2 cache if possible. That is, affinity tags are a hint to
the scheduler for thread placement.

The namespace of affinity tags is generally local to one task.
However, a child task created after the assignment of affinity tags by
its parent will share that namespace. In particular, a family of
forked processes may be created with a shared affinity namespace.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thanks for the quick answer. However I am not sure I'm understanding the motivation behind removing such kind feature. There is risk related to execute on specific core, but when accomplish with care, you can gain performance.


I've previously read the comment in the header and I was not really satisfy when it says:


Threads with the same affinity tag will be scheduled to
share an L2 cache "if possible".


Not having a warranty bother me a little and I am wondering how often "it's possible" to schedule threads on the same core. I imagine I will need to do some profiling to figure out. I would like to continue developing on mac without giving away performance.

Posted by
hugo.elmoznino
Up vote reply of hugo.elmoznino Down vote reply of hugo.elmoznino
Add a Comment

However I am not sure I'm understanding the motivation behind removing such kind feature.

This isn’t something we removed; neither OS X nor any of its ancestors ever had this feature.

Not having a warranty bother me a little …

This is something you’ll have to get used to on our platforms. Low-level APIs tend to be either under-specified or very tightly bound to the implementation. As Apple platforms evolve rapidly and prioritise binary compatibility, we generally prefer the former rather over the latter.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment