-
Notifications
You must be signed in to change notification settings - Fork 0
Per-thread cpu time #181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-thread cpu time #181
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -385,7 +385,7 @@ static int may_sleep(jl_ptls_t ptls) JL_NOTSAFEPOINT | |
|
||
extern _Atomic(unsigned) _threadedregion; | ||
|
||
JL_DLLEXPORT jl_task_t *jl_task_get_next(jl_value_t *trypoptask, jl_value_t *q, jl_value_t *checkempty) | ||
static jl_task_t *_jl_task_get_next(jl_value_t *trypoptask, jl_value_t *q, jl_value_t *checkempty) | ||
{ | ||
jl_task_t *ct = jl_current_task; | ||
uint64_t start_cycles = 0; | ||
|
@@ -538,6 +538,14 @@ JL_DLLEXPORT jl_task_t *jl_task_get_next(jl_value_t *trypoptask, jl_value_t *q, | |
} | ||
} | ||
|
||
JL_DLLEXPORT jl_task_t *jl_task_get_next(jl_value_t *trypoptask, jl_value_t *q, jl_value_t *checkempty) | ||
{ | ||
uint64_t t0 = jl_record_time_for_tls_metric(); | ||
jl_task_t *task = _jl_task_get_next(trypoptask, q, checkempty); | ||
jl_increment_timing_tls_metric(jl_current_task->ptls, scheduler_time, jl_record_time_for_tls_metric() - t0); | ||
return task; | ||
} | ||
Comment on lines
+541
to
+547
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this got lost in the handoff, but the original plan was to not record the current time twice for the "fast-path" of task switching. The concern is that adding two syscalls can meaningfully slow down task switching, and the idea was that we probably don't need to do this anyway since the time we'd be measuring in the fast-path case is trivial (we believe). So ideally I think we'd want to only do this in the slow paths inside jl_task_get_next? BUT to be honest, I find your approach much cleaner and clearer - and it's nice that we would get an accurate measure of that switch time which is supposed to be cheap......... AND we are going to need something like this anyway for the per-task CPU time in https://relationalai.atlassian.net/browse/RAI-30482... So maybe if we could solve the vDSO / fast instruction problem, then we could do it this way after all? |
||
|
||
#ifdef __cplusplus | ||
} | ||
#endif |
Uh oh!
There was an error while loading. Please reload this page.