Thread affinity cpu core

Question

Hugo Elmoznino OP

Created Mar ’16

Replies 3

Boosts 0

Views 6.3k

Participants 3

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!

Answered by DTS Engineer in 128101022

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"

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’16

Accepted Answer

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"

0

Answer 2

hugo.elmoznino OP

Mar ’16

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.

0

Answer 3

DTS Engineer OP

Apple

Mar ’16

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"

0