linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Markus Metzger <markus.t.metzger@intel.com>
Cc: ak@suse.de, hpa@zytor.com, linux-kernel@vger.kernel.org,
	tglx@linutronix.de, markut.t.metzger@intel.com,
	markus.t.metzger@gmail.com, suresh.b.siddha@intel.com,
	roland@redhat.com, akpm@linux-foundation.org,
	mtk.manpages@gmail.com, Alan Stern <stern@rowland.harvard.edu>
Subject: Re: x86, ptrace: support for branch trace store(BTS)
Date: Mon, 10 Dec 2007 21:20:52 +0100	[thread overview]
Message-ID: <20071210202052.GA26002@elte.hu> (raw)
In-Reply-To: <20071210123809.A14251@sedona.ch.intel.com>


[ Cc:-ed Alan Stern a'ka kwatch fame - Alan might be interested in this 
  too. ]

hi Markus,

finally had time to take a closer look at the design of your 
Branch-Trace-Support-via-ptrace-on-x86 patchset. I think we'll need to 
work some more on general API issues.

here's the current proposed API:

+       case PTRACE_BTS_MAX_BUFFER_SIZE:
+       case PTRACE_BTS_ALLOCATE_BUFFER:
+       case PTRACE_BTS_GET_BUFFER_SIZE:
+       case PTRACE_BTS_READ_RECORD:
+       case PTRACE_BTS_CONFIG:
+       case PTRACE_BTS_STATUS:

i can see a couple of open questions:

1) PTRACE_BTS_MAX_BUFFER_SIZE

why is a trace buffer size limit visible to user-space? It's 4000 
entries right now:

     #define PTRACE_BTS_BUFFER_MAX 4000

it would be more flexible if user-space could offer arbitrary sized 
buffers, which the kernel would attempt to mlock(). Then those pages 
could be fed to the BTS MSR. I.e. there should be no hard limit in the 
API, other than a natural resource limit.

2) struct bts_struct

the structure of it is hardwired:

the basic unit is an array of bts_struct:

 +struct bts_struct {
 +       enum bts_qualifier qualifier;
 +       union {
 +               /* BTS_BRANCH */
 +               struct {
 +                       long from_ip;
 +                       long to_ip;
 +               } lbr;
 +               /* BTS_TASK_ARRIVES or
 +                  BTS_TASK_DEPARTS */
 +               unsigned long long timestamp;
 +       } variant;
 +};

while other CPUs (on other architectures, etc.) might have a different 
raw format for the trace entries. So it would be better to implement BTS 
support in kernel/ptrace.c with a general trace format, and to provide a 
cross-arch API (only implemented by arch/x86 in the beginning) to 
translate the 'raw' trace entries into the general format.

3)

it would certainly be useful for some applications to have a large 
"virtual" trace buffer and a small "real" trace buffer. The kernel would 
use BTS high-watermark interrupts to feed the real trace buffer into the 
larger "virtual" trace buffer. This way we wouldnt even have to use 
mlock() to pin down the trace buffer.

	Ingo

  reply	other threads:[~2007-12-10 20:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-10 11:38 [patch 1/4] x86: remove bad comment Markus Metzger
2007-12-10 20:20 ` Ingo Molnar [this message]
2007-12-11 10:34   ` x86, ptrace: support for branch trace store(BTS) Metzger, Markus T
2007-12-11 14:53     ` Ingo Molnar
2007-12-12  9:18       ` Metzger, Markus T
2007-12-12 11:03         ` Ingo Molnar
2007-12-12 12:23           ` Metzger, Markus T
2007-12-13 10:29             ` Ingo Molnar
2007-12-13 12:51               ` Metzger, Markus T
2007-12-13 13:08                 ` Ingo Molnar
2007-12-13 16:06                   ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20071210202052.GA26002@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@gmail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=markut.t.metzger@intel.com \
    --cc=mtk.manpages@gmail.com \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).