lkml.org 
[lkml]   [2004]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.425 / U:4.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site