Description
The hard-coded 20us sysmon
tick in the runtime appears to be far too aggressive for minority architectures.
Our storage controllers run a single-core 800MHz arm cpu, which runs single-threaded workloads between 10 and 20 times slower than my desktop Intel machine.
Most of our product-level benchmarks improved substantially (5-10%) when I manually adjusted the minimum tick to 2ms on our arm devices. (Our use-case benefits from particularly long syscall ticks, since we tend to make read
and write
syscalls with large buffers, and those can take a long time even if they never actually block in I/O. Also, as you might imagine, the relative cost of thread creation and destruction on this system is quite high.)
Perhaps the runtime should calibrate the sysmon tick based on the performance of a handful of trivial syscalls (getpid()
, etc). Similarly, the tick could be adjusted upwards if an m
wakes up within a millisecond (or so) of being kicked off its p
. Perhaps someone with a better intuition for the runtime can suggest something heuristically less messy.
Thanks,
Phil