Use oxide-tokio-rt rather than #[tokio::main]
#523
Conversation
As described in [RFD 579], we are now recommending certain non-default Tokio runtime configurations in all software we deploy in production. The [`oxide-tokio-rt`] crate provides a way to easily get these common recommended configurations by using its functions to initialize the runtime rather than `#[tokio::main]` Presently, `oxide-tokio-rt` does the following: - Enables DTrace probes for Tokio runtime events using [`tokio-dtrace`] - Disables the [LIFO slot optimization][lifo], which was the root cause of omicron#8334 But, we anticipate that if there are additional Tokio configurations which we want to recommend in the future, we'll add them here as well. In particular, I think the new DTrace probes added by `tokio-dtrace` will potentially be very useful if issues like the stuck `mgd` reconciler task we observed in dogfood are ever encountered again in production. This commit updates `dendrite` to initialize the Tokio runtime using `oxide-tokio-rt`. I've added a Clippy config for warning on uses of `#[tokio::main]`, as well, to avoid forgetting to use `oxide-tokio-rt` if new binaries are added. All the configs we set currently in `oxide-tokio-rt` requires the `tokio_unstable` RUSTFLAGS cfg, but it looks like that's already being set, so that shouldn't be a problem. I've changed every binary to use `oxide-tokio-rt` with the exception of `mg-package` --- it didn't seem necessary to use the production-like config there and maybe avoiding an additional dependency to fetch would make it build slightly faster, although I'm unconvinced. I did change the lab binaries to use `oxide-tokio-rt`, as I figured that the DTrace probes could come in handy there. [RFD 579]: https://rfd.shared.oxide.computer/rfd/0579 [`oxide-tokio-rt`]: https://github.com/oxidecomputer/oxide-tokio-rt [`tokio-dtrace`]: https://github.com/oxidecomputer/tokio-dtrace [lifo]: https://rfd.shared.oxide.computer/rfd/0579#_disabling_the_lifo_slot_optimization
|
CI failure looks unrelated: we timed out installing a package. I'm restarting that one. |
Is this referring to the Dendrite |
Ah, whoops, you're right, that was Dendrite, never mind. Fortunately, I've also opened a similar PR over there. |
As described in RFD 579, we are now recommending certain non-default Tokio runtime configurations in all software we deploy in production. The
oxide-tokio-rtcrate provides a way to easily get these common recommended configurations by using its functions to initialize the runtime rather than#[tokio::main]Presently,
oxide-tokio-rtdoes the following:tokio-dtraceBut, we anticipate that if there are additional Tokio configurations which we want to recommend in the future, we'll add them here as well.
This commit updates
maghemiteto initialize the Tokio runtime usingoxide-tokio-rt. I've added a Clippy config for warning on uses of#[tokio::main], as well, to avoid forgetting to useoxide-tokio-rtif new binaries are added. All the configs we set currently inoxide-tokio-rtrequires thetokio_unstableRUSTFLAGS cfg, but it looks like that's already being set, so that shouldn't be a problem.I've changed every binary to use
oxide-tokio-rtwith the exception ofmg-package--- it didn't seem necessary to use the production-like config there and maybe avoiding an additional dependency to fetch would make it build slightly faster, although I'm unconvinced. I did change the lab binaries to useoxide-tokio-rt, as I figured that the DTrace probes could come in handy there.