[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1244641411.13761.11850.camel@twins>
Date: Wed, 10 Jun 2009 15:43:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Metzger, Markus T" <markus.t.metzger@...el.com>
Cc: Ingo Molnar <mingo@...e.hu>, "mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"oleg@...hat.com" <oleg@...hat.com>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: RE: [tip:tracing/core] x86, bts: reenable ptrace branch trace
support
On Wed, 2009-06-10 at 14:32 +0100, Metzger, Markus T wrote:
> >-----Original Message-----
> >From: Peter Zijlstra [mailto:peterz@...radead.org]
> >Sent: Wednesday, June 10, 2009 3:29 PM
> >To: Metzger, Markus T
> >Cc: Ingo Molnar; mingo@...hat.com; hpa@...or.com; linux-kernel@...r.kernel..org; tglx@...utronix.de;
> >oleg@...hat.com; linux-tip-commits@...r.kernel.org
> >Subject: RE: [tip:tracing/core] x86, bts: reenable ptrace branch trace support
> >
> >On Wed, 2009-06-10 at 14:22 +0100, Metzger, Markus T wrote:
> >>
> >> The Debug Store interface is completely in-kernel. It does not expose
> >> anything to the outside world.
> >>
> >> What we expose is a ptrace interface for branch tracing.
> >> That this is built on top of Debug Store is completely hidden.
> >> The Debug Store interface may be changed without impacting the
> >> user-visible part at any time.
> >>
> >> I do think that a ptrace interface makes sense since debuggers are the
> >> targeted users for branch tracing.
> >>
> >> I don't see why we should not merge the fixes now and then rework the
> >> in-kernel parts as needed for supporting PEBS.
> >
> >Ok, so what is all that account_locked_memory() for?
>
> To allow debuggers (users) to decide how much memory they want to spend
> on branch tracing.
But that is the debug store, right? User visible through some mlock
accounting and limit.
Furthermore, it appears there is an interface for setting the size,
that's also user visible and not fixable after the fact.
Once you want to multiplex cpu-wide and per task BTS/PEBS contexts,
there is no choice but to view the DS as a cpu resource, not a task
resource, therefore you cannot specify a size, nor attribute it to
specific tasks mm accounting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists