On Sat, Oct 20, 2018 at 07:41:36PM +0200, Borislav Petkov wrote:
> Dropping stable.
>
> On Sat, Oct 20, 2018 at 07:41:58AM -0700, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > The Intel microcode revision space is unsigned. Inside Intel there are
> >
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode revisionss. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite different
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode revisionss. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite different
On Sun, Oct 21, 2018 at 12:20:47PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Sat, 20 Oct 2018, Andi Kleen wrote:
> > On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> > > On Fri, 19 Oct 2018, Andi Kleen wrote:
> > > There is no point t
On Sun, Oct 21, 2018 at 12:20:47PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Sat, 20 Oct 2018, Andi Kleen wrote:
> > On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> > > On Fri, 19 Oct 2018, Andi Kleen wrote:
> > > There is no point t
On Wed, Oct 24, 2018 at 11:53:54AM -0700, Andy Lutomirski wrote:
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> wrote:
> >
> > From: Andi Kleen
> >
> > Add C intrinsics and assembler macros for the new FSBASE and GSBASE
> > instructions.
> >
&
On Wed, Oct 24, 2018 at 11:53:54AM -0700, Andy Lutomirski wrote:
> On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae
> wrote:
> >
> > From: Andi Kleen
> >
> > Add C intrinsics and assembler macros for the new FSBASE and GSBASE
> > instructions.
> >
&
> > void perf_event_mmap(struct vm_area_struct *vma)
> > {
> > struct perf_mmap_event mmap_event;
> >
> > if (!atomic_read(_mmap_events))
> > return;
> >
> > }
> >
>
> Thanks. I'll add the nr_mmap_events check in V2.
No, that's the wrong check here. The PEBS
> > void perf_event_mmap(struct vm_area_struct *vma)
> > {
> > struct perf_mmap_event mmap_event;
> >
> > if (!atomic_read(_mmap_events))
> > return;
> >
> > }
> >
>
> Thanks. I'll add the nr_mmap_events check in V2.
No, that's the wrong check here. The PEBS
> +void perf_event_munmap(void)
> +{
> + struct perf_cpu_context *cpuctx;
> + unsigned long flags;
> + struct pmu *pmu;
> +
> + local_irq_save(flags);
> + list_for_each_entry(cpuctx, this_cpu_ptr(_cb_list),
> sched_cb_entry) {
Would be good have a fast path here that checks
> +void perf_event_munmap(void)
> +{
> + struct perf_cpu_context *cpuctx;
> + unsigned long flags;
> + struct pmu *pmu;
> +
> + local_irq_save(flags);
> + list_for_each_entry(cpuctx, this_cpu_ptr(_cb_list),
> sched_cb_entry) {
Would be good have a fast path here that checks
>
> Can someone at least confirm whether unwinding from a function prologue via
> .eh_frame (but without .debug_frame) should actually be possible?
Yes it should be possible. Asynchronous unwind tables should work
from any instruction.
-Andi
>
> Can someone at least confirm whether unwinding from a function prologue via
> .eh_frame (but without .debug_frame) should actually be possible?
Yes it should be possible. Asynchronous unwind tables should work
from any instruction.
-Andi
> So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
It's default (64bit since always and 32bit now too) Unless someone disabled it.
However libm might be partially written in assembler and hand written assembler
often has problems with unwind tables because the programmer
> So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
It's default (64bit since always and 32bit now too) Unless someone disabled it.
However libm might be partially written in assembler and hand written assembler
often has problems with unwind tables because the programmer
Milian Wolff writes:
>
> After more digging, it turns out that I've apparently chased a red herring.
> I'm running archlinux which isn't shipping debug symbols for libm.
64bit executables normally have unwind information even when stripped.
Unless someone forcefully stripped those too.
You can
Milian Wolff writes:
>
> After more digging, it turns out that I've apparently chased a red herring.
> I'm running archlinux which isn't shipping debug symbols for libm.
64bit executables normally have unwind information even when stripped.
Unless someone forcefully stripped those too.
You can
From: Andi Kleen
The Intel microcode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcode revision
From: Andi Kleen
The Intel microcode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcode revision
On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Andi Kleen wrote:
>
> > > > + u32 min_ucode;
> > > > +};
> > > > +
> > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_u
On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Andi Kleen wrote:
>
> > > > + u32 min_ucode;
> > > > +};
> > > > +
> > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_u
On Sat, Oct 20, 2018 at 03:42:05PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Fri, 19 Oct 2018, Andi Kleen wrote:
> > Change the comparison to unsigned. With that the loading works
> > as expected.
> >
>
> I assume that wants a fixes tag and needs to be backpo
On Sat, Oct 20, 2018 at 03:42:05PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Fri, 19 Oct 2018, Andi Kleen wrote:
> > Change the comparison to unsigned. With that the loading works
> > as expected.
> >
>
> I assume that wants a fixes tag and needs to be backpo
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode revisionss. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite different
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode revisionss. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite different
From: Andi Kleen
The Intel ucode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcodes in the Linux driver
From: Andi Kleen
The Intel ucode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcodes in the Linux driver
> > + u32 min_ucode;
> > +};
> > +
> > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id
> > *match)
>
> What's the point of returning the struct pointer? Shouldn't it be enough to
> make it return bool? Also the function name really should reflect that this
> checks
> > + u32 min_ucode;
> > +};
> > +
> > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id
> > *match)
>
> What's the point of returning the struct pointer? Shouldn't it be enough to
> make it return bool? Also the function name really should reflect that this
> checks
On Wed, Oct 17, 2018 at 12:56:10PM +0200, Pavel Machek wrote:
> Hi!
>
> 6a012288 suggests I throw away 1GB on RAM. On 3GB system.. that is not
> going to be pleasant.
Just rebuild your kernel with PAE? I assume your CPU supports it.
This will also give you NX, which if you're really worried
On Wed, Oct 17, 2018 at 12:56:10PM +0200, Pavel Machek wrote:
> Hi!
>
> 6a012288 suggests I throw away 1GB on RAM. On 3GB system.. that is not
> going to be pleasant.
Just rebuild your kernel with PAE? I assume your CPU supports it.
This will also give you NX, which if you're really worried
> 4. Results
> - Without this optimization, the guest pmi handling time is
> ~450 ns, and the max sampling rate is reduced to 250.
> - With this optimization, the guest pmi handling time is ~9000 ns
> (i.e. 1 / 500 of the non-optimization case), and the max sampling
>
> 4. Results
> - Without this optimization, the guest pmi handling time is
> ~450 ns, and the max sampling rate is reduced to 250.
> - With this optimization, the guest pmi handling time is ~9000 ns
> (i.e. 1 / 500 of the non-optimization case), and the max sampling
>
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite difference
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite difference
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates
On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > note there's couple of changes that actually changed
> > > the number completely, like:
> > >
> > > -"Filter": &
On Tue, Oct 09, 2018 at 12:01:44PM +0200, Jiri Olsa wrote:
> On Wed, Oct 03, 2018 at 07:45:50AM -0700, Andi Kleen wrote:
> > > note there's couple of changes that actually changed
> > > the number completely, like:
> > >
> > > -"Filter": &
> > +> git clone https://github.com/intelxed/mbuild.git mbuild
> >
> > +> git clone https://github.com/intelxed/xed
> >
> > +> git clone https://github.com/intelxed/mbuild.git mbuild
> >
> > +> git clone https://github.com/intelxed/xed
> >
On Sat, Oct 06, 2018 at 04:14:54PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Oct 2018, Andi Kleen wrote:
> > +/*
> > + * Match specific microcodes or steppings.
>
> What means microcodes or steppings? If you mean microcode revisions then
> please spell it out and u
On Sat, Oct 06, 2018 at 04:14:54PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Oct 2018, Andi Kleen wrote:
> > +/*
> > + * Match specific microcodes or steppings.
>
> What means microcodes or steppings? If you mean microcode revisions then
> please spell it out and u
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min/max microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min/max microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite
> note there's couple of changes that actually changed
> the number completely, like:
>
> -"Filter": "edge=1,filter_band2=4000",
> +"Filter": "edge=1,filter_band2=30",
Thanks. Looks good. I'll fix the scripts to generate the uncore events.
-Andi
> note there's couple of changes that actually changed
> the number completely, like:
>
> -"Filter": "edge=1,filter_band2=4000",
> +"Filter": "edge=1,filter_band2=30",
Thanks. Looks good. I'll fix the scripts to generate the uncore events.
-Andi
> There is another variant of model/stepping micro code verification code in
> intel_snb_pebs_broken(). Can we please make this table based and use a
> common function? That's certainly not the last quirk we're going to have.
I have a patch to add a table driven microcode matcher for another fix.
> There is another variant of model/stepping micro code verification code in
> intel_snb_pebs_broken(). Can we please make this table based and use a
> common function? That's certainly not the last quirk we're going to have.
I have a patch to add a table driven microcode matcher for another fix.
Commit-ID: af3bdb991a5cb57c189d34aadbd3aa88995e0d9f
Gitweb: https://git.kernel.org/tip/af3bdb991a5cb57c189d34aadbd3aa88995e0d9f
Author: Andi Kleen
AuthorDate: Wed, 8 Aug 2018 00:12:07 -0700
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 10:14:31 +0200
perf/x86/intel: Add
Commit-ID: af3bdb991a5cb57c189d34aadbd3aa88995e0d9f
Gitweb: https://git.kernel.org/tip/af3bdb991a5cb57c189d34aadbd3aa88995e0d9f
Author: Andi Kleen
AuthorDate: Wed, 8 Aug 2018 00:12:07 -0700
Committer: Ingo Molnar
CommitDate: Tue, 2 Oct 2018 10:14:31 +0200
perf/x86/intel: Add
From: Andi Kleen
- Move the function from builtin-stat to evlist for reuse
- Rename to evlist to match purpose better
- Pass the evlist as first argument.
- No functional changes
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 29 ++---
tools/perf/util
From: Andi Kleen
- Move the function from builtin-stat to evlist for reuse
- Rename to evlist to match purpose better
- Pass the evlist as first argument.
- No functional changes
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 29 ++---
tools/perf/util
From: Andi Kleen
Implement a weak group fallback for perf record, similar to the existing perf
stat support.
This allows to use groups that might be longer than the available counters
without
failing.
Before:
$ perf record -e
'{cycles,cache-misses,cache-references,cpu_clk_unhalted.thread
From: Andi Kleen
Implement a weak group fallback for perf record, similar to the existing perf
stat support.
This allows to use groups that might be longer than the available counters
without
failing.
Before:
$ perf record -e
'{cycles,cache-misses,cache-references,cpu_clk_unhalted.thread
On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > > This new file descriptor argument doesn't exist today so it would
> > > > need to create a new system call with more arguments
> > >
&g
On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > > This new file descriptor argument doesn't exist today so it would
> > > > need to create a new system call with more arguments
> > >
&g
> > This new file descriptor argument doesn't exist today so it would
> > need to create a new system call with more arguments
>
> Is that true? The first argument is a pointer to a struct that
> contains its own size, so it can be expanded without an ABI break. I
> don't see any reason why you
> > This new file descriptor argument doesn't exist today so it would
> > need to create a new system call with more arguments
>
> Is that true? The first argument is a pointer to a struct that
> contains its own size, so it can be expanded without an ABI break. I
> don't see any reason why you
On Fri, Sep 28, 2018 at 06:40:17PM +0100, Mark Rutland wrote:
> On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > > There's also been prior discussion on these feature in other contexts
> > > (e.g. android expoits resulting from out-of-tree drivers). It would
On Fri, Sep 28, 2018 at 06:40:17PM +0100, Mark Rutland wrote:
> On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > > There's also been prior discussion on these feature in other contexts
> > > (e.g. android expoits resulting from out-of-tree drivers). It would
> Right now we have a single knob, which is poorly documented and that should
> be fixed first. But some googling gives you the information that allowing
> unprivilegded access is a security risk. So the security focussed sysadmin
Ah only if google could simply answer all our questions!
> will
> Right now we have a single knob, which is poorly documented and that should
> be fixed first. But some googling gives you the information that allowing
> unprivilegded access is a security risk. So the security focussed sysadmin
Ah only if google could simply answer all our questions!
> will
> There's also been prior discussion on these feature in other contexts
> (e.g. android expoits resulting from out-of-tree drivers). It would be
> nice to see those considered.
>
> IIRC The conclusion from prior discussions (e.g. [1]) was that we wanted
> finer granularity of control such that we
> There's also been prior discussion on these feature in other contexts
> (e.g. android expoits resulting from out-of-tree drivers). It would be
> nice to see those considered.
>
> IIRC The conclusion from prior discussions (e.g. [1]) was that we wanted
> finer granularity of control such that we
> Seems to me, these two features are _NOT_ only benefit for intel_pt,
> other hardware tracing (e.g. Arm CoreSight) can enable these features
> as well. This patch is to document only for intel_pt, later if we
> enable this feature on Arm platform we need to change the doc;
> alternatively we
> Seems to me, these two features are _NOT_ only benefit for intel_pt,
> other hardware tracing (e.g. Arm CoreSight) can enable these features
> as well. This patch is to document only for intel_pt, later if we
> enable this feature on Arm platform we need to change the doc;
> alternatively we
> + mutex_lock(_lock);
> + list_for_each_entry(pmu, , entry)
> + pmu->perf_event_paranoid = sysctl_perf_event_paranoid;
> + mutex_unlock(_lock);
What happens to pmus that got added later?
The rest looks good.
Can you post a non RFC version?
-Andi
> + mutex_lock(_lock);
> + list_for_each_entry(pmu, , entry)
> + pmu->perf_event_paranoid = sysctl_perf_event_paranoid;
> + mutex_unlock(_lock);
What happens to pmus that got added later?
The rest looks good.
Can you post a non RFC version?
-Andi
> Please me let me know if a valid issue so we can get a fix in.
If it crashes it must be a valid issue of course.
But I'm not sure about your bisect. Hard to see how my patch
could cause this. Sometimes bisects go wrong.
You verified by just reverting the patch?
First thing I would also try
> Please me let me know if a valid issue so we can get a fix in.
If it crashes it must be a valid issue of course.
But I'm not sure about your bisect. Hard to see how my patch
could cause this. Sometimes bisects go wrong.
You verified by just reverting the patch?
First thing I would also try
Commit-ID: a78cdee6fbb136694334ade4cedb331a9d0b4d5e
Gitweb: https://git.kernel.org/tip/a78cdee6fbb136694334ade4cedb331a9d0b4d5e
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:10 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:25:51 -0300
perf script
Commit-ID: a78cdee6fbb136694334ade4cedb331a9d0b4d5e
Gitweb: https://git.kernel.org/tip/a78cdee6fbb136694334ade4cedb331a9d0b4d5e
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:10 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:25:51 -0300
perf script
Commit-ID: 03a1f49f26482cf832e7f0157ae5da716d927701
Gitweb: https://git.kernel.org/tip/03a1f49f26482cf832e7f0157ae5da716d927701
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:07 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:16:19 -0300
tools lib
Commit-ID: 03a1f49f26482cf832e7f0157ae5da716d927701
Gitweb: https://git.kernel.org/tip/03a1f49f26482cf832e7f0157ae5da716d927701
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:07 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:16:19 -0300
tools lib
Commit-ID: 37fed3de555199733805a2d3e03aee7727c09ea4
Gitweb: https://git.kernel.org/tip/37fed3de555199733805a2d3e03aee7727c09ea4
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:09 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:20:03 -0300
perf script
Commit-ID: 37fed3de555199733805a2d3e03aee7727c09ea4
Gitweb: https://git.kernel.org/tip/37fed3de555199733805a2d3e03aee7727c09ea4
Author: Andi Kleen
AuthorDate: Tue, 18 Sep 2018 05:32:09 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:20:03 -0300
perf script
Commit-ID: c12e039d1233f24ab2726945f883037f47b26f1d
Gitweb: https://git.kernel.org/tip/c12e039d1233f24ab2726945f883037f47b26f1d
Author: Andi Kleen
AuthorDate: Thu, 13 Sep 2018 20:10:31 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:06:59 -0300
perf tools
Commit-ID: c12e039d1233f24ab2726945f883037f47b26f1d
Gitweb: https://git.kernel.org/tip/c12e039d1233f24ab2726945f883037f47b26f1d
Author: Andi Kleen
AuthorDate: Thu, 13 Sep 2018 20:10:31 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 19 Sep 2018 15:06:59 -0300
perf tools
Signed-off-by: Andi Kleen
---
v2: reflow line
v3: Print cycles in correct column
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 6232658c6f31..dbb0a780225c 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -913,7 +913,7 @@ static int grab_bb
Signed-off-by: Andi Kleen
---
v2: reflow line
v3: Print cycles in correct column
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 6232658c6f31..dbb0a780225c 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -913,7 +913,7 @@ static int grab_bb
group members. We can't do that, because it needs to be the
> same over the whole event list. This patch keeps it untouched
> again.
>
> Fixes: e9add8bac6c6 ("perf evsel: Disable write_backward for leader sampling
> group events")
> Reported-by: Andi Kleen
> L
group members. We can't do that, because it needs to be the
> same over the whole event list. This patch keeps it untouched
> again.
>
> Fixes: e9add8bac6c6 ("perf evsel: Disable write_backward for leader sampling
> group events")
> Reported-by: Andi Kleen
> L
From: Andi Kleen
Add a --insn-trace short hand option for decoding and disassembling
instruction streams for intel_pt. This automatically pipes the
output into the xed disassembler to generate disassembled instructions.
This just makes this use model much nicer to use
Before
% perf record -e
From: Andi Kleen
Add a --insn-trace short hand option for decoding and disassembling
instruction streams for intel_pt. This automatically pipes the
output into the xed disassembler to generate disassembled instructions.
This just makes this use model much nicer to use
Before
% perf record -e
From: Andi Kleen
By default perf script for itrace outputs sampled instructions or
branches. In my experience this is confusing to users because it's
hard to correlate with real program behavior. The sampling makes
sense for tools like report that actually sample to reduce
the run time, but run
From: Andi Kleen
By default perf script for itrace outputs sampled instructions or
branches. In my experience this is confusing to users because it's
hard to correlate with real program behavior. The sampling makes
sense for tools like report that actually sample to reduce
the run time, but run
From: Andi Kleen
For perf script brstackinsn also print a running cycles count.
This makes it easier to calculate cycle deltas for code sections
measured with LBRs.
% perf record -b -a sleep 1
% perf script -F +brstackinsn
...
_dl_sysdep_start+330:
7eff9f20583ainsn
From: Andi Kleen
For perf script brstackinsn also print a running cycles count.
This makes it easier to calculate cycle deltas for code sections
measured with LBRs.
% perf record -b -a sleep 1
% perf script -F +brstackinsn
...
_dl_sysdep_start+330:
7eff9f20583ainsn
Implement a range of improvements to make it easier to look
at itrace traces with perf script. Nothing here couldn't be done
before with some additional scripting, but add simple high
level options to make it easier to use.
% perf record -e intel_pt//k -a sleep 1
Show function calls:
% perf
From: Andi Kleen
Add a ftrace style --graph-function argument to perf script that allows
to print itrace function calls only below a given function. This
makes it easier to find the code of interest in a large trace.
% perf record -e intel_pt//k -a sleep 1
% perf script --graph-function
Implement a range of improvements to make it easier to look
at itrace traces with perf script. Nothing here couldn't be done
before with some additional scripting, but add simple high
level options to make it easier to use.
% perf record -e intel_pt//k -a sleep 1
Show function calls:
% perf
From: Andi Kleen
Add a ftrace style --graph-function argument to perf script that allows
to print itrace function calls only below a given function. This
makes it easier to find the code of interest in a large trace.
% perf record -e intel_pt//k -a sleep 1
% perf script --graph-function
From: Andi Kleen
Add short cut options to print PT call trace and call-ret-trace,
for calls and call and returns. Roughly corresponds to ftrace
function tracer and function graph tracer.
Just makes these common use cases nicer to use.
% perf record -a -e intel_pt// sleep 1
% perf script --call
From: Andi Kleen
Add short cut options to print PT call trace and call-ret-trace,
for calls and call and returns. Roughly corresponds to ftrace
function tracer and function graph tracer.
Just makes these common use cases nicer to use.
% perf record -a -e intel_pt// sleep 1
% perf script --call
> +int intel_pmu_enable_save_guest_lbr(struct kvm_vcpu *vcpu)
> +{
> + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> + struct perf_event *event;
> + struct perf_event_attr attr = {
> + .type = PERF_TYPE_RAW,
> + .size = sizeof(attr),
> + .pinned = true,
701 - 800 of 19746 matches
Mail list logo
