Async/await behaviour and CPU affinity

[enclave-alistair]

I've got a dotnet app that does a lot of high-throughput IO, and we use async/await everywhere to scale the throughput to a large number of active sessions (mostly TCP and UDP, with some P/Invokes on the other end). Whatever the case, there's a bunch of buffers involved, plus encryption and so on.

I found myself wondering, if I await an operation, is there any way to ask the completion handler of the task to execute on the same CPU as the initiating operation, to ensure the relevant memory remains in the L1/L2 cache for the CPU?

I imagine the answer will be no, since #21363 indicates thread affinity is not supported.

My dream I suppose is to be able to create a custom threadpool with affinity set, so there's effectively one threadpool per CPU, and for awaitable tasks to resume on the same CPU-bound threadpool that initiated the operation.

I can also imagine that the .NET team has already looked into this and said "it wouldn't help, the switch between threads is already bad enough that the extra affinity doesn't bring any gains".

[Clockwork-Muse]

... have you considered something like spinning up multiple versions of the application, each one bound to only one CPU by OS utilities?

[enclave-alistair]

Interesting, but not doable; the application needs to share a single open device handle that doesn't support shared read/write.

[Xyncgas]

I am no expert I am interested though, because you are trying to beg Async to resume in the same cpu so it can use the cache that's there already
...If the budget was so tight maybe don't use Async, because if you are awaiting hardware concurrency benefits do you want cache in cpu to remain unchanged when you are waiting for hardware (networking interface) to respond or do you want other codes to execute and use cpu for themselves while the Async operation is awaiting to be resumed