RE: [tip:tracing/core] Revert "x86, bts: reenable ptrace branchtrace support"

[Metzger, Markus T]

>-----Original Message-----
>From: Ingo Molnar [mailto:mingo@xxxxxxx]
>Sent: Thursday, June 11, 2009 11:41 PM
>To: Metzger, Markus T
>Cc: Peter Zijlstra; linux-kernel@xxxxxxxxxxxxxxx; mingo@xxxxxxxxxx; hpa@xxxxxxxxx; oleg@xxxxxxxxxx;
>tglx@xxxxxxxxxxxxx; linux-tip-commits@xxxxxxxxxxxxxxx
>Subject: Re: [tip:tracing/core] Revert "x86, bts: reenable ptrace branch trace support"
>
>
>* Metzger, Markus T <markus.t.metzger@xxxxxxxxx> wrote:
>
>> >-----Original Message-----
>> >From: Ingo Molnar [mailto:mingo@xxxxxxx]
>> >Sent: Thursday, June 11, 2009 12:22 PM
>> >To: Peter Zijlstra
>> >Cc: Metzger, Markus T; linux-kernel@xxxxxxxxxxxxxxx; mingo@xxxxxxxxxx; hpa@xxxxxxxxx;
>oleg@xxxxxxxxxx;
>> >tglx@xxxxxxxxxxxxx; linux-tip-commits@xxxxxxxxxxxxxxx
>> >Subject: Re: [tip:tracing/core] Revert "x86, bts: reenable ptrace branch trace support"
>> >
>> >
>> >* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> >
>> >> On Thu, 2009-06-11 at 07:30 +0100, Metzger, Markus T wrote:
>> >> > >-----Original Message-----
>> >> > >From: tip-bot for Ingo Molnar [mailto:mingo@xxxxxxx]
>> >> > >Sent: Thursday, June 11, 2009 1:37 AM
>> >> > >To: linux-tip-commits@xxxxxxxxxxxxxxx
>> >> > >Cc: hpa@xxxxxxxxx; mingo@xxxxxxxxxx; peterz@xxxxxxxxxxxxx; Metzger, Markus T; oleg@xxxxxxxxxx;
>> >> > >tglx@xxxxxxxxxxxxx; mingo@xxxxxxx
>> >> > >Subject: [tip:tracing/core] Revert "x86, bts: reenable ptrace branch trace support"
>> >> > >
>> >> > >Commit-ID:  511b01bdf64ad8a38414096eab283c7784aebfc4
>> >> > >Gitweb:     http://git.kernel.org/tip/511b01bdf64ad8a38414096eab283c7784aebfc4
>> >> > >Author:     Ingo Molnar <mingo@xxxxxxx>
>> >> > >AuthorDate: Thu, 11 Jun 2009 00:32:00 +0200
>> >> > >Committer:  Ingo Molnar <mingo@xxxxxxx>
>> >> > >CommitDate: Thu, 11 Jun 2009 00:32:00 +0200
>> >> > >
>> >> > >Revert "x86, bts: reenable ptrace branch trace support"
>> >> > >
>> >> > >This reverts commit 7e0bfad24d85de7cf2202a7b0ce51de11a077b21.
>> >> > >
>> >> > >A late objection to the ABI has arrived:
>> >> > >
>> >> > >   http://lkml.org/lkml/2009/6/10/253
>> >> >
>> >> > I thought that this has been resolved. See for example http://lkml.org/lkml/2009/6/10/257.
>> >> >
>> >> > Peters concerns were that Debug Store details are exposed to user space, which is
>> >> > not the case. Debug Store itself is fully in-kernel and the expectation of a
>> >> > user-defined buffer can be implemented on top of the Debug Store changes that
>> >> > Peter expects are needed to support PEBS.
>> >> >
>> >> > A user-defined trace buffer size is required to support
>> >> > different usage models. Some users only need a small amount of
>> >> > trace, whereas others need a big amount. The interface will have
>> >> > to reflect that in some way.
>> >>
>> >> Right, your last email did explain how we could keep per task
>> >> in-kernel buffers and fill them from the DS and still have them of
>> >> user-specified size.
>> >>
>> >> That would indeed keep the proposed ABI workable, what I'm still
>> >> not liking is that this buffer is in-kernel, but I guess that
>> >> might be something for other people to have an opinion on.
>> >
>> > Hm. Wrt. the ABI, wouldnt it make more sense to expose this PMU
>> > feature via perfcounters: a sampling hw-branch-executions
>> > counter, with interval=1.
>> >
>> > That would give the exact existing semantics, plus a lot lot
>> > more. Markus?
>>
>> What more would we get?
>
>There's numerous direct functionality advantages:
>
> - We will get all the sampling features of perfcounters such as
>   timed samples, CPU ID samples. Some will be approximate (timing),
>   some precise (CPU ID).
>
> - We will get the advanced workflow isolation features: we could
>   sample on a per CPU basis (system-wide BTS), and we could sample
>   child tasks automatically. The current code is limited to a
>   single task.
>
> - We will sample other types of information into the same outgoing
>   event buffer: for example branch-miss events, intermixed with BTS
>   records. This could help not just the narrow purpose of
>   debugging, but also the purpose of performance analysis.
>
> - There's a rich and fast/efficient VFS based APIs to wait for
>   event overflows: poll(), read(), mmap().
>
> - Remote sampling via perfcounters is transparent, while ptrace
>   sampling can be seen by apps.
>
>There's maintenance advantages as well from the x86 architecture and
>scheduler maintenance point of view:
>
> - We would have a single facility handling the Debug Store, and
>   we'd have almost all pieces in place for PEBS support in
>   perfcounters as well so there's good synergy.

I'm not exactly sure what you are proposing.

There currently is a single facility handling Debug Store which is used
by perfmon for PEBS sampling and by BTS for branch tracing. The ptrace
interface is a thin layer that allows debuggers to easily access the
part that is relevant for them.


Are you proposing a single abstraction of sampling and branch tracing events
using records of different sizes in one big stream?

regards,
markus.

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/