Conversation
Darksonn
added
A-tokio
|
This particular trick has previously been discussed in this blog post, where we said that we would not implement this. |
Thanks for your reply. I have read this article before, and I still want to try the effect of sysmon. According to the data obtained from this attempt, I have a better understanding of the reason mentioned in the article. It seems that we really don't need to introduce sysmon. Sorry to bother you, I should discuss it in Discussions first. |
|
I’m not against a sysmon style strategy. What is key is that it isn’t applied against everything. What we could investigate is an annotation (“might_block”), which opts into the sysmon. We also need to think about how to deal with blocking the rest of the task (e.g. select). |
3 participants
Motivation
At present, there may be a few CPU-bound tasks in our system occasionally. These tasks may execute for about 100ms. If all worker threads are executing these tasks, they will block other small tasks.
Solution
In this PR, we implemented sysmon introduced by golang. This will greatly reduce the latency of small tasks without increasing CPU usage.
small task
small task
big task
big task
We use workload.rs and workload-server.rs to simulate small tasks, big tasks.
tokio-sysmon-taskset limits the CPU usage by using taskset, tokio-sysmon-taskset and tokio are using the same CPU usage, ~400%. tokio-sysmon-without-takset doesn't use taskset, its CPU usage is about 553%.