> >
> > 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 ta
On 10/06/2012 10:57 AM, Steven Rostedt wrote:
>
> 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" tabl
On Sat, Oct 06, 2012 at 02:26:17PM -0400, Steven Rostedt wrote:
> On Sat, 2012-10-06 at 19:32 +0200, Borislav Petkov wrote:
>
> > > 2) Are the tracepoints done in a way that it's not going to cause "ABI"
> > > issues. If not then we need to redesign the tracepoints.
> >
> > Btw, this we should be
On Sat, 2012-10-06 at 19:32 +0200, Borislav Petkov wrote:
> > 2) Are the tracepoints done in a way that it's not going to cause "ABI"
> > issues. If not then we need to redesign the tracepoints.
>
> Btw, this we should be asking ourselves about *all* TPs, especially if
> they're in generic code.
On Sat, Oct 06, 2012 at 10:51:45AM -0400, Steven Rostedt wrote:
> On Sat, 2012-10-06 at 15:05 +0200, Borislav Petkov wrote:
> > What I'm missing with all those patches on LKML is: here's a patch that
> > doesn't add a new feature but gives us n% improv with this and that
> > workload. I wish we had
On Sat, 2012-10-06 at 15:05 +0200, Borislav Petkov wrote:
> What I'm missing with all those patches on LKML is: here's a patch that
> doesn't add a new feature but gives us n% improv with this and that
> workload. I wish we had more of those instead of the gazillion new
> features each 3 months.
On Fri, Oct 05, 2012 at 10:57:41PM -0400, Steven Rostedt wrote:
> > The problem I'm seeing is the constant "oh, just a little bit more." My
> > experience over the years is that there is always demand for "just one
> > more debug feature", each of which has negible cost, because they always
> > us
On Fri, 2012-10-05 at 17:16 -0700, H. Peter Anvin wrote:
> On 10/05/2012 07:13 AM, Steven Rostedt wrote:
> >
> > Peter,
> >
> > I agree that the IDT version is a zero cost in performance, where as the
> > tracepoint version is a negligible cost in performance. But my worry is
> > the complexity (
On 10/05/2012 07:13 AM, Steven Rostedt wrote:
>
> Peter,
>
> I agree that the IDT version is a zero cost in performance, where as the
> tracepoint version is a negligible cost in performance. But my worry is
> the complexity (read error prone and possible openings of security
> exploits) worth it
On Tue, 2012-10-02 at 19:10 +, Seiji Aguchi wrote:
> > >
> > > If I misunderstand something, please let me know.
> > >
> >
> > Quite.
> >
> > These functions are being invoked from the IDT, which is an indirect
> > pointer structure. When not being traced, there is absolutely no
> > reason
> >
> > If I misunderstand something, please let me know.
> >
>
> Quite.
>
> These functions are being invoked from the IDT, which is an indirect pointer
> structure. When not being traced, there is absolutely no
> reason why it should go through a thunk with tracepoints.
I agree that the cost
On 09/27/2012 03:33 PM, Seiji Aguchi wrote:
> Hi,
>
>> ... except the cost can be reduced to zero *AND* be made into a more general
>> mechanism by simply hooking the IDT.
>
> Thank you for giving me the comment.
> In my understanding, we can introduce a more general mechanism by
> sandwiching
Hi,
> ... except the cost can be reduced to zero *AND* be made into a more general
> mechanism by simply hooking the IDT.
Thank you for giving me the comment.
In my understanding, we can introduce a more general mechanism by sandwiching
an existing handler between tracepoints.
The pseudo code
On 09/21/2012 05:40 PM, Seiji Aguchi wrote:
Those x86 specific ones are not really frequently raised vectors, so
enabling them all won't affect performance and readability of the
traces too much.
... except the cost can be reduced to zero *AND* be made into a more
general mechani
14 matches
Mail list logo