Should _ebpf_epoch_cpu_table[cpu_id].non_preemptible_epoch be split into entry/exit epochs?

[Alan-Jowett]

Hypothesis:
Splitting _ebpf_epoch_cpu_table[cpu_id].non_preemptible_epoch into entry/exit epoch fields + lock will give preferrable behavior and permit removal of the _ebpf_epoch_update_cpu_entry DPC.

Note:
Splitting non_preemptible_epoch into enter/exit epochs requires a lock to synchronize them, but would permit removal of the DPC (code can adopt a similar pattern to the one used for threads).

[shankarseal]

The main principles of the epoch logic are:

1. No piece of memory allocated by epoch_alloc() can be freed until all active threads (may be swapped out if passive), were created strictly after epoch_free() was called on that memory.
2. Avoid lock/inter-locked operation on epoch_enter()/exit() as they are called on every ebpf program invocation - and there can be million such invocations per second (e.g. XDP hooks in high througput incoming network traffic).
3. epoch_free() is assumed to be a relatively infrequent operation - and its OK to grab lock perform interlocked operation.

Issues:
For non-preemptible threads (NPT), there is always ambiguity about whether a CPU at epoch X means a NPT is currently executing on that core or not. As a result any memory with free_epoch > X cannot be deleted. To make forward progress a DPC is queued every 1 ms to update CPU epoch. Question is which is more detrimental to perf?
queueing a DPC every 1 ms and stalling threads that are actually doing useful work.
interlocked operation on every epoch_enter() or exit().

Can we take a middle approach? When the garbage collector thread runs, it can check the amount of zombied memory that are pending deletion, and if it exceeds a threshold, only then queue DPC?

[Alan-Jowett]

I think I know how to make this performant and a lot simpler:

1. Only access _ebpf_epoch_cpu_table at IRQL = Dispatch.
2. Only access _ebpf_epoch_cpu_table[current_cpu].

Given that IRQL = Dispatch implies non-preemption, this means the thread accessing _ebpf_epoch_cpu_table[current_cpu] always has exclusive access.

[Alan-Jowett]

Still unable to get a solution that operates correctly without a lock per-CPU that is acquired on the _enter/_exit path. I am willing to entertain proposals that can fix this as long as they are demonstratably correct.