Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0

[Ingo Molnar]

* Karim Yaghmour <karim@xxxxxxxxxxx> wrote:

> >i just added something ad-hoc.
>
> Yes, I understood as much. I'm suggesting it because a lot of people
> who need such ad-hoc functionality could easily be using relayfs.

the latency tracer is pretty specialized for a number of reasons, i'm
not sure there's a good match between the two. If relayfs were in the
mainline kernel i'd consider reusing parts of it.

> >I wanted it to be accurate across
> >interrupt entries. I have not looked at the relayfs locking but how does
> >it solve that?
> 
> cmpxchg (basically: try reserve; if fail retry; else write), with
> per-cpu buffers.

this still does not solve all problems related to irq entries: if the
IRQ interrups the tracing code after a 'successful reserve' but before
the 'else write' point, and the trace is printed/saved from an
interrupt, then there will be an incomplete entry in the trace.

also, there is the problem of timestamp atomicity: if an IRQ interrupts
the tracing code and the trace timestamp is taken in the 'else' branch
then a time-reversal situation can occur: the entry will have a
timestamp _larger_ than the IRQ trace-entries. With cli/sti all tracing
entries occur atomically: either fully or not at all.

> >Also, cli/sti makes it obviously SMP-safe and is pretty
> >cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
> >because the tracer interacts with that code quite heavily.)
> 
> No preempt_disable/enable found in the lockless logging in relayfs.

it would have to do that on PREEMPT_REALTIME. The irq flag solves both
the races, the predictability problem and the preemption problem nicely.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/