thread_policy_set(1) returned 46

Developer Tools & Services Xcode Xcode Sanitizers and Runtime Issues OSLog

MichaelCavallaro03 OP

Created Feb ’22

Replies 19

Boosts 0

Views 3.9k

Participants 6

Hi there,

Recently we have been seeing thread_policy_set(1) returned 46 flooding our log output. We tracked down that the flood of this is coming from a separate library whom we've contacted.

They mentioned that this is a Apple internal message that comes up in the library's deadlock detector. The proposed solution was to use OS_ACTIVITY_MODE env var to hide the logs as suggested from the post on StackOverflow..

I tried all suggestions from that StackOverflow post, which were able to hide other system logs generated from Apple but it specifically did not hide the thread_policy_set(1) returned 46

What I am hoping to understand is:

Why does this message come up? I see that the documentation for this on Apple's docs is very limited.
Is this message's visibility controllable via a separate variable in project settings outside of modifying settings for all logs?
As a last resort, how can I disable only this log message?

Thank you!

Boost

DTS Engineer OP

Apple

May ’22

I guess it's from <sys/errno.h>.

Correct.

This came out in macOS 10.5

Wow, that’s a blast from the past.

Honestly, if that doc had been written today it would’ve been more circumspect about what to expect from this API.

On the general affinity front, I don’t have a great answer. One of my colleagues here in DTS supports that side of things (they wrote the response discussed in this thread).

Regarding your big picture issue, I suspect that you’ve already seen the Tune CPU job scheduling for Apple silicon games tech talk. If not, it’s well worth the effort.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

AlecazamTGC OP

May ’22

Seems like the new Swift threading model is all about no more threads than cores, and keeping each core busy with work. So that implementation is locking threads to cores via affinity. That's exactly why we also need affinity control. And this api doesn't appear to be supplied for C++ code.

I hadn't seen that presentation, so digging into it. Thanks!

DTS Engineer OP

Apple

May ’22

Seems like the new Swift threading model is all about no more threads than cores

Right. That is, in general, the way forward. Be aware, however, that Swift concurrency is still very new, and it’s handling of things like QoS is quite rudimentary. Right now the low-level C APIs you’re currently using give you much more control than you can get through Swift concurrency.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

AlecazamTGC OP

May ’22

Seems that p-cores can drop off during thermal constraint. That would make affinity assignments more challenging. We're now setting round-robin 45/41 priority as per the talk, set qos 31 on non-important threads, but have audio threads at super high fifo priority. But we can control where any of this runs consistently, and we have that and priority on all other platforms. We're not even sure if based on these vague numbers that we consistent get p- or e-cores. That makes consistent performance tuning a lot more difficult.