Add thread_ids::Vector option to Profile.init()
#39746
Conversation
- This option will configure julia's profiler to only run on the provided thread ids! :) - Adds a global int mask to allow toggling profiling for up to 64 threads in a performant way. I think if you have more than 64 threads, it's okay that you can't profile individual threads since it's unlikely to be very meaningful by then...
| n_cur = ccall(:jl_profile_maxlen_data, Csize_t, ()) | ||
| delay_cur = ccall(:jl_profile_delay_nsec, UInt64, ())/10^9 | ||
| if n === nothing && delay === nothing | ||
| _init_threadid_filter(thread_ids) |
There was a problem hiding this comment.
Hmm, now that I think about it, I guess thread_ids should be "sticky," too, like the other params? I was trying to be super safe here to make sure it's always reset back to normal to preserve backwards compatibility, but I think that is someone if using the girls, it would make more sense for it to work like the others.
I can change this in the morning. :)
Should this also get added to the return value? Would we want to return the mask or the array? If we want to return the array, I can either add a getter for the mask and reconstruct the vector from it, or we can store the vector as a global in Julia, in parallel with the mask. I think a getter for the mask makes more sense.
| end | ||
| threadid_mask |= 0x1 << (tid-1) | ||
| end | ||
| ccall(:jl_profile_init_threadid_filter, Cvoid, (UInt64,), threadid_mask) |
There was a problem hiding this comment.
Oops, we should move this outside the if block, so that we can reset the filter when passing an empty vector.
|
Hmm, I would rather record on which thread the backtrack was collected. In pprof I think you can add that as a field. I suspect that would be more useful than limiting profiling to a specific set of threads (how do you know that they are of more interest then the others) |
|
Hrmmm yeah, you're maybe right. ... Can you filter out by threadid in pprof if we add it as a field? I guess in the worst case we could do it in our julia API even if you can't do it through the GUI. Hehe blech, but Valentin it will be so much harder to make the changes to pipe this through everywhere! This is the easier/lazier option 😅 Still, i think you're probably right that this would be a nice thing to record, even if we didn't want to filter it... it'll just be more work to get that set up i think.
Yeah, I was basically only imagining using this on thread 1, because e.g. if you have some tasks that you only schedule via In this case, we were screwing around with trying to fix our server's responsiveness problems with this silly package: https://github.com/RelationalAI-oss/DevilSpawn.jl. But it didn't actually have much impact on responsiveness, and I was curious to see why, since in theory we shouldn't be scheduling (as much) stuff on the main thread, so i was interested to see what was still scheduling there and blocking the thread. |
|
Thanks @NHDaly, this issue bugs me too (julia-vscode/julia-vscode#1881) I think there's an argument that it would be good to have both the ability to select which threads to profile, and add the thread info into the backtraces. Given selecting which threads to profile is relatively simple and wouldn't need a change of any of the profile data reading downstream code, could this PR be considered before both are implemented? @NHDaly I'd be happy to test this. Perhaps before I do that there seem to be some pending changes, and a rebase given a lot has changed since this |
|
+1 Thanks @IanButterworth - i agree! I think those are good points. Especially if you're running on a system with close to a hundred threads, you'd need a super big buffer, and if you know ahead of time which threads you want to profile, it can help a lot to apply this filter up front 👍 Let's try to pick this up again 👍 |
With migration, how do you know? I maintain my objection xD |
A few possible reasons:
|
(Nathan, I just really want to nerd-snipe you into doing the hard work xD) |
This option will configure julia's profiler to only run on the
provided thread ids! :)
Adds a global int mask to allow toggling profiling for up to 64
threads in a performant way. I think if you have more than 64 threads,
it's okay that you can't profile individual threads since it's
unlikely to be very meaningful by then...
Fixes #39743