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

[Robert Wisniewski]

Ingo Molnar writes:
 > 
 > * 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.

:-)  it's nice we all have a sense of humor.


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

That is incorrect.  The system behavior needed to generate an incomplete
entry is far more complicated and unlikely than what you describe.


 > 
 > 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

If you do not care about performance then you're probably right, this is
fine.  If you are concerned about the time it takes to go through the
sequence of code, then probably not.


Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@xxxxxxxxxxxxxx
-
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/