ELC: A PREEMPT_RT roadmap

i3839 — Tue, 03 May 2011 16:29:18 +0000

> 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
special properties.

That said, reducing the preemption-disabled window is always good.

ELC: A PREEMPT_RT roadmap

dashesy — Mon, 02 May 2011 19:08:30 +0000

I subscribed to LWN specially to to read this article, and hopefully more and more -rt related articles to come.

LWN: Comments on "ELC: A PREEMPT_RT roadmap"

ELC: A PREEMPT_RT roadmap

ELC: A PREEMPT_RT roadmap