LKML Archive on
help / color / mirror / Atom feed
From: Andi Kleen <>
To: "Metzger, Markus T" <>
Cc:,,,,, "Siddha, Suresh B" <>
Subject: Re: ptrace API extensions for BTS
Date: Fri, 7 Dec 2007 14:04:06 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Friday 07 December 2007 13:01:28 Metzger, Markus T wrote:
> >From: Andi Kleen [] 
> >Sent: Freitag, 7. Dezember 2007 12:18
> >> I would like to settle the discussion and find an interface that
> >> everybody can agree to, so I can implement that interface and we can
> >> move forward with the patch.
> >
> >The most efficient interface would be zero copy with tracer 
> >user process
> >supplying memory that is pinned (get_user_pages()) subject to the
> >mlock rlimit. Then kernel telling the CPU to directly log into
> >that.
> That would require users to understand all kinds of BTS formats
> and to detect the hardware they are running on in order to interpret
> the data.

That's true. I guess it could be abstracted in a library, but doing
it all in kernel is indeed nicer.

Ok in theory you could go fancy and put the library into the vDSO
which runs in ring 3. Then it would be tied to the kernel again.

> So far, there are two different formats. But one of them is wasting
> an entire word of memory per record. I could imagine that this would
> change some day.
> Other architectures would likely use an entirely different format.
> Users who want to support several architectures would benefit from
> a common format for this from-to branch information.

I guess some other users would prefer higher performance, but yes
there are probably both types. I don't know what is more important.

> Is there some other metric that would allow me to order BTS 
> chunks for different threads?

With Out-of-order CPUs exact global metrics are pretty difficult.
At which point of the instruction execution would you measure? 

Anyways if RDTSC doesn't work the only global alternatives are much slower
(like southbridge timers) or very inaccurate (jiffies) 

I would just drop it since it'll likely always be somewhat misleading.


  reply	other threads:[~2007-12-07 13:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07  9:11 Metzger, Markus T
2007-12-07 11:18 ` Andi Kleen
2007-12-07 12:01   ` Metzger, Markus T
2007-12-07 13:04     ` Andi Kleen [this message]
2007-12-07 13:36       ` Metzger, Markus T
2008-01-30  7:25 ` Roland McGrath
2008-01-30 10:32   ` Metzger, Markus T
2008-01-30 11:01     ` stephane eranian
2008-01-30 12:52       ` Metzger, Markus T
2008-01-30 13:39         ` stephane eranian
2008-01-31 11:15         ` stephane eranian
2008-01-31 17:45           ` Metzger, Markus T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: ptrace API extensions for BTS' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).