> >
> > 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
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
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"
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 table, and
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
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
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
> >
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
use the
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 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 more
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.
I
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 asking
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
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
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 why it should go
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 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 (read error
> >
> > 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
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 can be
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
>
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
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/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 an
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
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
28 matches
Mail list logo
