Added features to support per-core runtime

[zhuxiujia]

Is your feature request related to a problem? Please describe. In some scenarios, task theft is not necessary, such as nginx, where task theft simply adds unnecessary locking overhead。 There is also a counterexample, Actix, which adds its own abstraction of Actix-RT to support each core runtime (thus doubling performance) Describe the solution you'd like Provides a Features switching option that can support each core runtime.

Describe alternatives you've considered when this feature is enabled, tokio::spawn() will be submitted to the runtime local queue of each thread according to the load algorithm

Additional context

tokio = { version = "1", features = ["rt-peer-thread"] }

[Darksonn]

I'm quite certain that this is a duplicate of some existing issue somewhere.

[ileixe]

@zhuxiujia Did you mean "per-core" similar to per core architecture which is another runtime glommio is pursuing? If then I'm also looking for the answer from Tokio side as well.

@Darksonn If I'm correctly understanding this issue, could you please locate the existing issue? I could not find it.

[zhuxiujia]

@zhuxiujia Did you mean "per-core" similar to per core architecture which is another runtime glommio is pursuing? If then I'm also looking for the answer from Tokio side as well.

@Darksonn If I'm correctly understanding this issue, could you please locate the existing issue? I could not find it.

Yeah, something like that. Or with rt-multi-thread and enable rt-peer-thread, the spawn task is then handed directly to the background thread. There is no task theft between threads, so locking overhead can be avoided

I guess task stealing does improve per-thread load balancing though。 But the time overhead of locks and channels is not negligible, and perhaps it should be up to Tokio users to decide if they need to enable it. And you can currently see something like Actix-Web/ntex crates wrapping tokio want to be peer thread runtime , that is improve performance

[Darksonn]

We have previously discussed adding a third runtime flavor that works like this. I couldn't find the discussion - it might have happened outside of GitHub. We discussed it when we were changing the runtime builder as part of the 0.3.0 release, and I believe it wasn't implemented then because we didn't need a breaking change to add it later.

[Noah-Kennedy]

I think we need to have a larger discussion as well around this in relation to io_uring, where we need to rethink some of the sharing/stealing we do between workers, as io_uring is not as conducive to sharing the driver as epoll is.

[nyabinary]

This would require a huge rewrite of Tokio, wouldn't it?