KfRaiseIrql usersim API performance renders it hard to use in stress

[Alan-Jowett]

In kernel mode, this is a relatively light weight API. The usersim version is very heavy and causes tests to timeout due to cost.

[Alan-Jowett]

[mtfriesen]

Nit with title: the performance might not match, but the performance is poor partly because it tries very hard to match the observable functional behavior of kernel mode. Do you know what the bottleneck is?

[Alan-Jowett]

Looks like SetThreadPriority and SetThreadGroupAffinity are super slow. I will try profiling to narrow down why.

[mtfriesen]

Darn. If we're hitting the SetThreadGroupAffinity function, then we must not have already been at dispatch level when the raise IRQL routine is called, so we can't trivially optimize away this function.

[Alan-Jowett]

Correct. The test case that breaks is running BPF programs at passive level, which requires raising and lowering IRQL on every epoch enter / exit.

[mtfriesen]

For context, I added a considerable amount of overhead in PR #53. Previously this routine was somewhat lighter weight, but also allowed a variety of observable misbehavior, including passive threads and other DPCs preempting dispatch level code on the same processor.

Perhaps we could add a config knob to relax some of those constraints if tests are known not to depend on dispatch level code being properly serialized WRT each other and/or WRT passive threads.