[Hexagon] Host API for changing stack size#5708
[Hexagon] Host API for changing stack size#5708aankit-ca wants to merge 10 commits intohalide:mainfrom
Conversation
| * @param datalen, length of data | ||
| * @retval, 0 on success | ||
| */ | ||
| extern "C" __QAIC_REMOTE_EXPORT int __QAIC_REMOTE(remote_session_control)(uint32_t req, void *data, uint32_t datalen) __QAIC_REMOTE_ATTRIBUTE; |
There was a problem hiding this comment.
Isn't this code just resolving to the definition in libadsprpc_shim.cpp? In that case, I think most of the stuff in this header is unnecessary (and may be wrong, e.g. dllexport stuff), we can just make a libadsprpc_shim.h and declare it there.
src/runtime/hexagon_host.cpp
Outdated
|
|
||
| debug(user_context) << "halide_hexagon_set_thread_params\n"; | ||
| if (!remote_set_thread_params) { | ||
| // This runtime doesn't support changing the performance target. |
There was a problem hiding this comment.
performance target -> thread params?
| __android_log_print(ANDROID_LOG_ERROR, "halide", "Error: Could not set stack_size to %d. remote_session_control returned %d.", | ||
| stack_size, retval); | ||
| } | ||
| return retval; |
There was a problem hiding this comment.
I think maybe this should return either halide_error_code_success or halide_error_code_generic_error, I think the current code is returning a Qualcomm error code as something that will probably be interpreted as a Halide error code. The other remote runtime functions are different because we implement them (that said, I've seen qualcomm error codes returned in crash conditions, so this is a bit janky for the other functions too).
There was a problem hiding this comment.
I've moved this code to hexagon_host.cpp.
| // This is deprecated. | ||
| typedef halide_hexagon_power_t halide_hvx_power_perf_t; | ||
|
|
||
| /** Set fastRPC thread priority and staksize. Set thread params before making |
|
|
||
| /** Set fastRPC thread priority and staksize. Set thread params before making | ||
| * any RPC calls. halide_hexagon_set_thread_params. */ | ||
| extern int halide_hexagon_set_thread_params(void *user_context, int priority, int stack_size); |
There was a problem hiding this comment.
Maybe this and halide_hexagon_set_thread_priority should be documented together so they can share the more detailed comment about priorities?
There was a problem hiding this comment.
I don't know if halide_hexagon_set_thread_priority mentions that lower int values mean higher priority. We should mention it in the comments here regardless.
There was a problem hiding this comment.
halide_hexagon_set_thread_priority does mention about this: "Smaller number for higher priority"
| typedef halide_hexagon_power_t halide_hvx_power_perf_t; | ||
|
|
||
| /** Set fastRPC thread priority and staksize. Set thread params before making | ||
| * any RPC calls. halide_hexagon_set_thread_params. */ |
There was a problem hiding this comment.
Remove stray function name here?
There was a problem hiding this comment.
s/staksize/stack size/
|
|
||
| /** Set fastRPC thread priority and staksize. Set thread params before making | ||
| * any RPC calls. halide_hexagon_set_thread_params. */ | ||
| extern int halide_hexagon_set_thread_params(void *user_context, int priority, int stack_size); |
There was a problem hiding this comment.
I don't know if halide_hexagon_set_thread_priority mentions that lower int values mean higher priority. We should mention it in the comments here regardless.
| halide_hexagon_power_hvx_off(user_context); | ||
| } | ||
|
|
||
| WEAK int halide_hexagon_set_thread_params(void *user_context, int priority, int stack_size) { |
There was a problem hiding this comment.
As discussed offline just now, renaming this to halide_hexagon_set_remote_thread_params makes more sense?
| */ | ||
|
|
||
| #define HALIDE_RUNTIME_HEXAGON | ||
| #define FASTRPC_THREAD_PARAMS (1) |
There was a problem hiding this comment.
This (and remote_rpc_thread_params) shouldn't be in this header, they aren't used in the Halide API. I think they should be in hexagon_host.cpp
There was a problem hiding this comment.
Done. Also I noticed somewhere the default priority value for fastrpc threads was 192 and not 100. I'll check with @pranavb-ca once.
| int stack_size; // user thread stack size, pass -1 to use default | ||
| }; | ||
|
|
||
| /** Set the default priority/stack_size for Halide Hexagon user threads: |
There was a problem hiding this comment.
Does set_remote_thread_params apply to all FastRPC threads, or just the calling thread? At first I thought it was the latter, but now the docs make it sound like the former...
There was a problem hiding this comment.
I'm not sure about this. Will confirm with Pranav and get back to you.
There was a problem hiding this comment.
It will apply to all fastrpc threads spawned by the process and not just he calling thread.
| * - Priority 0 is reserved for OS usage | ||
| * If this routine is not called, the priority will default to 100. | ||
| * This is intended to be called before dispatching any pipeline. */ | ||
| * If halide_hexagon_set_thread_priority routine is not called, the priority |
There was a problem hiding this comment.
@aankit-ca - With PipelineContext removed halide_remote.cpp, I don't think the plumbing for halide_hexagon_set_thread_priority to get the priority set for each thread in the parallel thread pool exists any more. We should either completely remove this function or change it to use remote_session_control where available and fall back to its current approach now.(I don't know if many people use it though). We should also use the new thread_params mechanism to set the thread priority and/ or stack size.
// to set only the priority
halide_hexagon_set_remote_thread_params(NULL, 10, -1);
// to set only the stack size
halide_hexagon_set_remote_thread_params(NULL, -1, 1024 * 32);
// to set both
halide_hexagon_set_remote_thread_params(NULL, 10, 1024 * 32);
| debug(user_context) << " " << result << "\n"; | ||
| if (result != 0) { | ||
| error(user_context) << "set_remote_thread_params faiiled.\n"; | ||
| return result; |
There was a problem hiding this comment.
Will this fastrcp error code not get conflated with a halide runtime error code?
There was a problem hiding this comment.
Yes, it will, this should return -1 or some other halide error code.
|
Looks like this PR still needs some cleanup before it can land? |
|
Where does this PR stand? |
|
@steven-johnson The PR needs some changes. Unfortunately my dev machine is down due to power outage since last week. I'll update the PR soon. |
|
@steven-johnson & @dsharletg - Due to the winter storm that Texas saw last week, our office where all our hardware for building and testing is saw a massive power outage. As if that wasn't enough, a sprinkler pipe burst caused flooding in our office. As such we are scrambling to bring up some testing infrastructure for our group. @aankit-ca will post an update on this PR once we have some capability restored. |
|
Thanks for the update! |
|
This PR has been sitting around for a few months now; is it still active? |
|
@steven-johnson Sorry this PR fell through the cracks. But I think we need this PR. I'll resume working on this. |
Thanks for the update! |
|
We now have another stack usage regression causing crashes. Is this PR something that is ready to merge early this week? |
src/runtime/hexagon_host.cpp
Outdated
| debug(user_context) << "halide_hexagon_set_remote_thread_params\n"; | ||
| if (!set_remote_thread_params) { | ||
| // This runtime doesn't support changing the thread params. | ||
| return -1; |
There was a problem hiding this comment.
In other similar "optional" cases where the runtime function is missing, we return 0.
| debug(user_context) << " " << result << "\n"; | ||
| if (result != 0) { | ||
| error(user_context) << "set_remote_thread_params faiiled.\n"; | ||
| return result; |
There was a problem hiding this comment.
Yes, it will, this should return -1 or some other halide error code.
Saw this late. I've most of the changes ready. Will put them up for review soon. |
43f3969 to
b1fc7e1
Compare
|
@dsharletg @pranavb-ca PTAL |
|
@dsharletg @pranavb-ca Ping |
| WEAK remote_power_mode_fn remote_set_performance_mode = nullptr; | ||
| WEAK remote_thread_priority_fn remote_set_thread_priority = nullptr; | ||
| WEAK remote_set_thread_params_fn remote_set_thread_params = nullptr; | ||
| WEAK remote_session_control_fn remote_thread_session_control = nullptr; |
There was a problem hiding this comment.
Should thread be included in the name here? According to the Hexagon SDK docs,remote_session_control can be used for more than just setting thread parameters. We may want to reuse this function for setting other non-thread parameters in the future.
In fact, I've been playing around with using "unsigned" execution mode (discussed here: #5200 (comment)). Using this branch, I was able to reuse remote_thread_session_control to enable said mode.
|
@aankit-ca - is there any path forward to merging this functionality? How were the binary files generated? In a manner equivalent to #7741? |
@dsharletg @pranavb-ca Users will have to call halide_hexagon_set_thread_params with thread priority and stack size before any RPC call.