[Profiler] Limit calls to recordThreadInfo
#74888
Conversation
Summary: So far as I can tell, `recordThreadInfo` only needs to be called once per thread. Once we have thread local subqueues we can easily manage this by simply calling it in the subqueue constructor. Test Plan: The effect on single threaded overhead is pretty minimal, but it improves stress test overhead from ~6.1 us to ~1.4us since we're no contending over the lock in Kineto. Reviewed By: chaekit Differential Revision: D34811694 fbshipit-source-id: 93ebf67f8ec223944f8178c423e01c22fe17803f
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 32ad337 (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Please report bugs/suggestions to the (internal) Dr. CI Users group. |
|
This pull request was exported from Phabricator. Differential Revision: D34811694 |
Summary: Pull Request resolved: #74888 So far as I can tell, `recordThreadInfo` only needs to be called once per thread. Once we have thread local subqueues we can easily manage this by simply calling it in the subqueue constructor. Test Plan: The effect on single threaded overhead is pretty minimal, but it improves stress test overhead from ~6.1 us to ~1.4us since we're no contending over the lock in Kineto. Reviewed By: chaekit Differential Revision: D34811694 fbshipit-source-id: da1047f7ae43af048773610a0f250fa514c67989
|
Hey @robieta. |
2 participants
Summary: So far as I can tell,
recordThreadInfoonly needs to be called once per thread. Once we have thread local subqueues we can easily manage this by simply calling it in the subqueue constructor.Test Plan: The effect on single threaded overhead is pretty minimal, but it improves stress test overhead from ~6.1 us to ~1.4us since we're no contending over the lock in Kineto.
Reviewed By: chaekit
Differential Revision: D34811694