[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D413872974@USINDEM103.corp.hds.com>
Date: Thu, 11 Oct 2012 17:04:03 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: "H. Peter Anvin" <hpa@...or.com>,
Steven Rostedt <rostedt@...dmis.org>
CC: "Thomas Gleixner (tglx@...utronix.de)" <tglx@...utronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"'mingo@...e.hu' (mingo@...e.hu)" <mingo@...e.hu>,
"x86@...nel.org" <x86@...nel.org>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>,
Satoru Moriya <satoru.moriya@....com>
Subject: RE: [PATCH v4] trace,x86: add x86 irq vector tracepoints
> >
> > I didn't say anything magic, but a table of pointers that are very
> > critical for the system running. Should we implement it with a single
> > switch, like we discussed in San Diego to do with the system call table?
> >
> > That is, have a "normal" table, and a "trace" table. The trace table
> > points to functions that have tracepoints. The first enabler of
> > tracing switches the table to use the tracepoints, and the last
> > disabler switches it back?
> >
>
> That is certainly a reasonable implementation option. It is slightly less usable than it is for system calls, though, because the vectors in
> the IDTs are somewhat scrambled and so you can't just do an indirect jump to the original vector content. This does get messy
> because you also want to preserve registers...
>
Peter, Steven,
Thank you for explaining the reason why you think a time penalty should be zero
and discussing its implementation.
I will update my patch so that a time penalty makes zero and submit it shortly.
Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists