> The realtime developers have talked with the per-CPU folks and they
> "see our pain". The right solution is use inline functions to annotate
> the real atomic accesses, so that the preemption-disabled window can
> be reduced. "Right now, there is a massive amount of code protected
> by preempt_disable()", he said.
Hm, to me it seems something else than preemption disable is needed
for this situation.
What is wanted is to atomically change some data, in a very fast way.
To achieve this, the data is kept per-CPU, so no concurrent access
happens, and preemption is disabled to avoid being interrupted by
another task on the same CPU touching the same data.
But what's really needed is avoiding preemption by tasks that would
touch the same data, being preempted by other tasks is fine.
So instead of using preemption, something more alike to coroutines
can be used: Have a per-CPU data region task ID, used as a kind of
lockless lock. When a task wants to access per-CPU data, it checks
the ID first. If it already is set, it schedules to that task. If
not, it writes its own ID atomically (but without lock prefix) and
can access the data safely. It's basically a per-CPU mutex with
That said, reducing the preemption-disabled window is always good.