Messages in this thread | | | Date | Fri, 15 Oct 2004 16:58:59 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 |
| |
* Robert Wisniewski <bob@watson.ibm.com> wrote:
> Ingo Molnar writes: > > > > * Robert Wisniewski <bob@watson.ibm.com> wrote: > > > > > > > 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. > > > > ah, but i'm talking about actual first-hand experience, not supposition. > > It happens quite easily with latency traces (which are saved/printed > > from IRQ entries) and it can be very annoying to analyze. My first > > tracers tried to do things without the IRQ flag, so i've seen both > > methods. > > This means that other code you've written has this happen, it doesn't mean > the fundamental model is broken. Also, if what you claim is true and there > really is this contention, then it both means that 1) there are many many > other higher priority tasks in the system than the one you are trying to > trace, and 2) it's questionable whether you want to use locks.
_interrupts_. The latency tracer does traces like:
00000002 0.022ms (+0.000ms): mark_page_accessed (zap_pte_range) 00000002 0.022ms (+0.000ms): page_remove_rmap (zap_pte_range) 00000002 0.022ms (+0.000ms): free_page_and_swap_cache (zap_pte_range) 00000002 0.022ms (+0.001ms): put_page (zap_pte_range) 00010002 0.023ms (+0.000ms): do_IRQ (zap_pte_range) 00010002 0.023ms (+0.000ms): do_IRQ (<00000000>) 00010003 0.024ms (+0.004ms): mask_and_ack_8259A (do_IRQ) 00010003 0.029ms (+0.000ms): redirect_hardirq (do_IRQ) 00010000 0.029ms (+0.000ms): handle_IRQ_event (do_IRQ)
and i just pointed out why i didnt use relayfs.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |