d there is quite a few more I didn't realize have been using bits and
pieces, good.
- Arnaldo
Em Wed, Apr 14, 2021 at 11:07:39AM -0500, Rob Herring escreveu:
> x86 and arm64 can both support direct access of event counters in
> userspace. The access sequence is less than trivial and currently exists
> in perf test code (tools/perf/arch/x86/tests/rdpmc.c) with copies in
> projects such as
bageCollector
>
> Mostly true; but I suspect tools/perf might care, it has some longer
> running things in.
Yes, and now we have 'perf daemon' that is long running.
- Arnaldo
> > 'ret' is unknown when asprintf() failed.
> >
> > Reported-by: Hulk Robot
> > Signed-off-by: Zhen Lei
>
> Acked-by: Jiri Olsa
Thanks, applied.
- Arnaldo
> thanks,
> jirka
>
> > ---
> > tools/perf/util/data.c | 5 +++--
> > 1 f
Em Fri, Apr 16, 2021 at 02:41:13PM -0700, Ian Rogers escreveu:
> Relative path include works in the regular build due to -I paths but may
> break in other situations.
Thanks, applied.
- Arnaldo
> Signed-off-by: Ian Rogers
> ---
> tools/perf/arch/arm64/util/kvm-sta
Em Mon, Apr 19, 2021 at 09:39:37AM +0200, Martin Liška escreveu:
> @Arnaldo: May I please ping this?
Applied the refreshed version,
- Arnaldo
> Thanks,
> Martin
>
> On 4/8/21 12:08 PM, Martin Liška wrote:
> > On 4/7/21 10:25 PM, Arnaldo Carvalho de Melo wrote:
> >&
Em Mon, Apr 19, 2021 at 12:41:43PM +0300, alexander.anto...@linux.intel.com
escreveu:
> From: Alexander Antonov
>
> Resending V5 with added Acked-by: Namhyung Kim tag.
Thanks, applied.
- Arnaldo
> Thanks,
> Alexander
>
> The previous version can be fou
Em Mon, Apr 19, 2021 at 10:38:46PM +1000, Michael Ellerman escreveu:
> Kajol Jain writes:
> > Patch adds initial json/events for POWER10.
>
> Acked-by: Michael Ellerman
Thanks, applied.
- Arnaldo
> cheers
>
> > Signed-off-by: Kajol Jain
> > Tested
ed-off-by
> >
>
> You forgot to add the RB and AB you received. Since Arnaldo is responsible
> for
> the perf tools subsystem, please send another revision.
Yep, please collect Reported-by and Acked-by as you go sending new
versions of a patchset, the last one I don't have a prob
>
> (3) When build pahole from tar.gz source code, it still failed
> due to no libbpf submodule.
You're getting the tarball from the wrong place, you should get it from:
https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.xz
Please read the announcement:
https://lore.kernel
Em Thu, Apr 15, 2021 at 03:09:28PM -0500, Rob Herring escreveu:
> On Thu, Apr 15, 2021 at 2:37 PM Arnaldo Carvalho de Melo
> wrote:
> > Ok, b4 failed on it, probably some missing Reply to, so I'll apply it by
> > hand:
>
> That's my fault. A duplicate message-id is t
Em Thu, Apr 15, 2021 at 04:48:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 15, 2021 at 04:46:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Apr 14, 2021 at 03:53:36PM -0500, Rob Herring escreveu:
> > > On Wed, Apr 14, 2021 at 3:25 PM N
Em Thu, Apr 15, 2021 at 04:46:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Apr 14, 2021 at 03:53:36PM -0500, Rob Herring escreveu:
> > On Wed, Apr 14, 2021 at 3:25 PM Namhyung Kim wrote:
> > >
> > > On Thu, Apr 15, 2021 at 4:58 AM Rob Herring wrote:
>
t; > > parameters come from external callers. Add bounds checks and an
> > > unchecked __xyarray__entry().
> > >
> > > Cc: Peter Zijlstra
> > > Cc: Ingo Molnar
> > > Cc: Arnaldo Carvalho de Melo
> > > Cc: Mark Rutland
> > &
Em Thu, Apr 15, 2021 at 04:14:31AM +0900, Namhyung Kim escreveu:
> On Thu, Apr 15, 2021 at 3:23 AM Arnaldo Carvalho de Melo
> wrote:
> >
> > Em Wed, Apr 14, 2021 at 03:02:08PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Apr 15, 2021 at 01:41:35AM +
failed.
You forgot to research and add this:
Fixes: 6c502584438bda63 ("perf unwind: Call unwind__prepare_access for forked
thread")
So that the sta...@kernel.org guys can pick this up automagically and
apply this fix to the stable kernels.
I've added it.
Thanks, applied.
- Arnaldo
> Repor
Em Wed, Apr 14, 2021 at 04:08:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> [root@6db6d5ad9661 perf]# tools/perf/trace/beauty/fsconfig.sh
> static const char *fsconfig_cmds[] = {
> [0] = "SET_FLAG",
> [1] = "SET_STRING",
> [2] = &q
t;,/p" \
${linux_mount}
printf "};\n"
[root@6db6d5ad9661 perf]# tools/perf/trace/beauty/fsconfig.sh
static const char *fsconfig_cmds[] = {
[0] = "SET_FLAG",
[1] = "SET_STRING",
[2] = "SET_BINARY",
[3] = "SET_PATH",
[4] = "SET_PATH_EMPTY",
[5] = "SET_FD",
[6] = "CMD_CREATE",
[7] = "CMD_RECONFIGURE",
};
[root@6db6d5ad9661 perf]#
So I guess we can sweep thru tools/perf/trace/beauty/*.sh and simplify
things in other table generators?
Please consider this.
Thanks, applied.
- Arnaldo
Em Wed, Apr 14, 2021 at 03:02:08PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 15, 2021 at 01:41:35AM +0900, Namhyung Kim escreveu:
> > Hello,
> >
> > On Thu, Apr 15, 2021 at 1:07 AM Rob Herring wrote:
> > > +void *perf_evsel__mmap_base(struct p
CONFIG_([[:alnum:]_]+)[[:space:]]*=[[:space:]]*([[:digit:]]+)[[:space:]]*,.*'
> +sed -nr "s/$regex/\t[\2] = \"\1\",/p" ${linux_mount}
> printf "};\n"
Testing this, all working, I'll step back and ask you to remove that now
useless regex variable and do it directly in the now only line using it,
the sed one.
- Arnaldo
med in earlier, but at
least now this is getting traction, and the end result will be better
not just for the feature you've been dilligently working on,
Thank you for your persistence,
- Arnaldo
> Thanks,
> Namhyung
>
>
> > +
> > + return MMAP(evsel, cpu, thre
Hi,
Please take a look,
Best regards,
- Arnaldo
Arnaldo Carvalho de Melo (2):
perf evlist: Add a method to return the list of evsels as a string
perf record: Improve 'Workload failed' message printing events + what
was exec'ed
tools/perf/builtin-record.c | 8 ++--
tools
From: Arnaldo Carvalho de Melo
Before:
# perf record -a cycles,instructions,cache-misses
Workload failed: No such file or directory
#
After:
# perf record -a cycles,instructions,cache-misses
Failed to collect 'cycles' for the 'cycles,instructions,cache-misses'
workload
From: Arnaldo Carvalho de Melo
Add a 'scnprintf' method to obtain the list of evsels in a evlist as a
string, excluding the "dummy" event used for things like receiving
metadata events (PERF_RECORD_FORK, MMAP, etc) when synthesizing
preexisting threads.
Will be used to improve the err
Em Mon, Apr 12, 2021 at 03:22:29PM +0800, Yang Jihong escreveu:
> On 2021/3/31 10:18, Yang Jihong wrote:
> > On 2021/3/30 15:26, Namhyung Kim wrote:
> > > On Sat, Mar 27, 2021 at 11:16 AM Yang Jihong
> > > wrote:
> > > > On 2021/3/26 20:06, Arnaldo Carval
Em Tue, Apr 13, 2021 at 02:07:57PM -0500, Rob Herring escreveu:
> On Tue, Apr 13, 2021 at 1:39 PM Arnaldo Carvalho de Melo
> wrote:
> > > --- a/tools/lib/perf/evsel.c
> > > +int perf_evsel__mmap(struct perf_evsel *evsel, int pages)
> > > +{
> >
Em Tue, Apr 13, 2021 at 03:49:31PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 13, 2021 at 12:16:05PM -0500, Rob Herring escreveu:
> > Add __T_VERBOSE() so tests can add verbose output. The verbose output is
> > enabled with the '-v' command line option.
>
> Y
g test-evlist.c...OK
- running test-evsel.c...OK
[acme@five perf]$
I'm only getting a move verbose output for the Makefile steps, not from
the actual tests.
Perhaps if I read the last cset... will do that now.
- Arnaldo
> Signed-off-by: Rob Herring
> ---
> v5:
> - Pass verbose fl
{
> + int fd = FD(evsel, cpu, thread);
> + struct perf_mmap *map = MMAP(evsel, cpu, thread);
> +
> + if (fd < 0)
> + continue;
> +
> + perf_mmap__init(map, NULL, false, N
-1.21.tar.bz2
https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.sign
Thanks a lot to all the contributors and distro packagers, you're on the
CC list, I appreciate a lot the work you put into these tools,
Best Regards,
- Arnaldo
DWARF loader:
- Handle DWARF5 DW_OP_addrx
Hi Linus,
Please consider pulling,
Best regards,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:
Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)
are available in the Git repository at:
git
managed
> > >> "cycles" and "instructions" by default.
> > >
> > > well if you are already changing the tools why not change them to add
> > > modifier.. but I don't mind adding that .perfconfig stuff if you need
> > > that
> >
> > The tools I mentioned here don't use perf-stat, they just use
> > perf_event_open() and read the perf events fds. We want a config to make
>
> just curious, how those tools use perf_event_open?
I.e. do they use tools/lib/perf/? :-)
I guess they will use it now for getting that "struct
perf_event_attr_map_entry" and
the map name define.
> > "cycles" to use BPF by default, so that when the user (not these tools)
> > runs perf-stat, it will share PMCs with those events by default.
> I'm sorry but I still don't see the usecase.. if you need to change both
> tools,
> you can change them to use bpf-managed event, why bother with the list?
He wants users not to bother if they are using bpf based counters, this will
happen
automagically after they set their ~/.perfconfig with some command line Song
provides.
Then they will be using bpf counters that won't get exclusive access to those
scarce counters, the tooling they are using will use bpf-counters and all will
be well.
Right Song?
- Arnaldo
Agreed, maximum flexibility.
> For systems with BPF-managed perf events running in the background,
> .perfconfig makes sure perf-stat sessions will share PMCs with these
> background monitoring tools. 'b' modifier, on the other hand, is useful
> when the user knows there is opport
Em Wed, Apr 07, 2021 at 04:30:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 26, 2021 at 10:24:00AM +0100, Martin Liška escreveu:
> > On 2/23/21 8:47 PM, Arnaldo Carvalho de Melo wrote:
> > Sure. But I think the current format provides quite broken visual layout:
>
Em Fri, Feb 26, 2021 at 10:24:00AM +0100, Martin Liška escreveu:
> On 2/23/21 8:47 PM, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Feb 21, 2021 at 01:46:36PM +0100, Martin Liška escreveu:
> > > The patch changes the output format in 2 ways:
> > > - line number is dis
Em Fri, Mar 19, 2021 at 10:38:26AM +0100, Martin Liška escreveu:
> PING
Can you please try to refresh the patch? It isn't applying, probably my
bad for not having processed it already :-\
- Arnaldo
> On 2/26/21 10:24 AM, Martin Liška wrote:
> > On 2/23/21 8:47 PM, Arnaldo Carv
Em Wed, Apr 07, 2021 at 08:39:55AM -0700, Ian Rogers escreveu:
> SPE extended headers are >1 byte so ensure the buffer contains at
> least this before reading. This issue was detected by fuzzing.
Thanks, applied.
- Arnaldo
> Signed-off-by: Ian Rogers
> ---
> tools/perf/ut
;
> Reviewed-by: Andi Kleen
Thanks, applied.
- Arnaldo
mended event.
>
> The second and third patches addresses the inconsistency by defaulting all
> event codes and umask values to use lower cases and 0x%02x as their
> format.
>
> The final patch adds Zen3 events.
Thanks, applied.
- Arnaldo
> Cc: Peter Zijlstra
> Cc: Ingo Mo
ric
Thanks, applied.
- Arnaldo
> List of pre-defined events (to be used in -e):
>
> Metrics:
>
> bp_misp_flush
>[BP misp flush L3 topdown metric]
> branch_mispredicts
>[Branch mispredicts L2 topdown metric]
> core_bound
Em Wed, Apr 07, 2021 at 05:49:02PM +0800, johnny.che...@huawei.com escreveu:
> From: Chen Yi
>
> Delete one of the header files that are included twice.
Thanks, but I got a patch merged for this already.
- Arnaldo
> Signed-off-by: Chen Yi
> ---
> tools/perf/builtin-d
Em Tue, Apr 06, 2021 at 06:51:02PM +0800, Wan Jiabing escreveu:
> struct mem_info is defined at 22nd line.
> The declaration here is unnecessary. Remove it.
Thanks, applied.
- Arnaldo
> Signed-off-by: Wan Jiabing
> ---
> tools/perf/util/mem-events.h | 1 -
> 1 file c
ome (more) discussion would be in order.
Are you sure that potentially breaking existing scripts is ok in this
case?
Up to you, frankly.
- Arnaldo
> On Fri, Apr 2, 2021 at 6:37 AM Arnaldo Carvalho de Melo
> wrote:
>
> > Em Fri, Apr 02, 2021 at 06:40:20PM +0900, Namhyung Kim escrev
an Jiabing
>
> Acked-by: Namhyung Kim
>
> I think we can move all the forward declarations to the top
> (and sort them) as well.
Thanks, applied.
- Arnaldo
s used
if both are specified?
$ perf record -c 11 -F 99 true
Frequency and period can't be used the same time, -c 1 will be used.
- Arnaldo
> Suggested-by: Alexey Alexandrov
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/record.c | 8 +++-
> 1 file changed, 7
> >
> > Fixes: e558a5bd8b74 ("perf inject: Work with files")
> > Signed-off-by: Adrian Hunter
>
> Acked-by: Jiri Olsa
Thanks, applied.
- Arnaldo
Em Tue, Mar 30, 2021 at 08:19:10PM +0200, Martin Liška escreveu:
> On 3/30/21 5:42 PM, Arnaldo Carvalho de Melo wrote:
> > Trying to find V2
You said you would resend fixing up this:
+ OPT_BOOLEAN(0, "demangle", _conf.demangle,
+ "D
the delay in processing, applied.
- Arnaldo
> Signed-off-by: Fabian Hemmer
> ---
> tools/perf/tests/demangle-ocaml-test.c | 6 +++---
> tools/perf/util/demangle-ocaml.c | 12
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/tools/perf/tests/de
c6bd9aec7859a0503581312834fb197f1
> > (in tmp.perf/core branch), but we miss setting the same via options.
> >
> > Thank you,
> > Martin
> >
> > On 2/26/21 11:01 AM, Martin Liška wrote:
> > > On 2/23/21 8:49 PM, Arnaldo Carvalho de Melo wrote:
> > > >
Hi Linus,
Please consider pulling,
Best regards,
- Arnaldo
Tests at the end of this message:
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub
PDX-License-Identifier: GPL-2.0
>+#include
>+#include
>+#include
>+
>+#include "../../../util/event.h"
>+#include "../../../util/synthetic-events.h"
>+#include "../../../util/machine.h"
>+#include "../../../util/tool.h"
>+#includ
0x6(%rax),%rbx
1 0 545: movzbl (%rbx),%eax
10 13 cmp$0x4c,%al
↓ ja 5026
1 0 550: lea
v8::internal::FLAGDEFAULT_abort_on_contradictory_flags+0x457,%rdi
movslq (%rdi,%rax,4),%rax
9 8 add%rdi,%rax
So it seems to be working, what am I missing? Is this strictly non
group related?
- Arnaldo
On March 25, 2021 11:38:01 AM GMT-03:00, Peter Zijlstra
wrote:
>On Thu, Mar 25, 2021 at 10:01:35AM -0300, Arnaldo Carvalho de Melo
>wrote:.
>> > > Also for CPU_FTR_ARCH_31, capture the two cycle counter
>information in
>> > > two 16 bit field
mon.h
> > @@ -265,6 +265,10 @@
> > #define ISA207_SIER_DATA_SRC_SHIFT53
> > #define ISA207_SIER_DATA_SRC_MASK (0x7ull << ISA207_SIER_DATA_SRC_SHIFT)
> > +/* Bits in SIER2/SIER3 for Power10 */
> > +#define P10_SIER2_FINISH_CYC(sier2)(((sier2) >> (63 - 37)) &
> > 0x7fful)
> > +#define P10_SIER2_DISPATCH_CYC(sier2) (((sier2) >> (63 - 13)) &
> > 0x7fful)
> > +
> > #define P(a, b) PERF_MEM_S(a, b)
> > #define PH(a, b) (P(LVL, HIT) | P(a, b))
> > #define PM(a, b) (P(LVL, MISS) | P(a, b))
> > @@ -278,6 +282,6 @@ int isa207_get_alternatives(u64 event, u64 alt[], int
> > size, unsigned int flags,
> > const unsigned int ev_alt[][MAX_ALT]);
> > void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > struct pt_regs *regs);
> > -void isa207_get_mem_weight(u64 *weight);
> > +void isa207_get_mem_weight(u64 *weight, u64 type);
> > #endif
--
- Arnaldo
>
> Changes looks fine to me.
>
> Reviewed-by: Madhavan Srinivasan
So who will process the kernel bits? I'm merging the tooling parts,
Thanks,
- Arnaldo
>
> > Signed-off-by: Athira Rajeev
> > ---
> > arch/powerpc/include/asm/perf_event_server.h | 2 +-
>
e 14, so remove the
> duplicate one at line 28.
Thanks, applied.
- Arnaldo
> Signed-off-by: Wan Jiabing
> ---
> tools/perf/builtin-daemon.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
> index ace8772a4f03.
nt;/*24 8 */
u64time_enabled; /*32 8 */
u64time_running; /*40 8 */
/* size: 64, cachelines: 1, members: 5 */
/* padding: 16 */
} __attribute__((__aligned__(64)));
[acme@five c]$
- Arnaldo
Em Thu, Mar 25, 2021 at 12:39:34PM +0800, Wan Jiabing escreveu:
> struct evlist has been declared at 10th line.
> struct comm has been declared at 15th line.
> Remove the duplicate.
Thanks, applied.
- Arnaldo
> Signed-off-by: Wan Jiabing
> ---
> tools/perf/util/metricgroup
Em Wed, Mar 24, 2021 at 11:21:19AM -0700, Ian Rogers escreveu:
> On Wed, Mar 24, 2021 at 6:54 AM Borislav Petkov wrote:
> >
> > On Wed, Mar 24, 2021 at 10:43:20AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Borislav, was this addressed? Ian?
> >
> > Yap
t; Signed-off-by: Leo Yan
>
> Acked-by: Namhyung Kim
Thanks, applied.
- Arnaldo
of perf for me in
> tip.git/master. The reason being that non-x86 builds compile the
> intel-pt-decoder, which includes this file, but don't have their
> include paths set to find tools/arch/x86. I think we want to keep the
> relative paths.
Borislav, was this addressed? Ian?
- Arnaldo
e useful materials.
Thanks, applied.
- Arnaldo
> Signed-off-by: Tiezhu Yang
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aa84121..e1626db 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -
Em Tue, Mar 16, 2021 at 02:50:48PM +0100, Jiri Olsa escreveu:
> On Tue, Mar 16, 2021 at 09:56:26AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Mar 16, 2021 at 11:28:12AM +0900, Namhyung Kim escreveu:
> > > On Mon, Mar 15, 2021 at 10:28 PM Jiri Olsa wrote:
> > &g
With above commit the test logic for the eBPF relocation is obsolete.
> The loading of the eBPF now succeeds and the test always shows FAILED.
>
> This patch removes the sub test completely.
> Also a lot of eBPF program testing is done in the eBPF test suite,
> it also contains tests for global variables.
Thanks, applied.
- Arnaldo
ike this:
>
> perf data convert --to-json out.json
Interesting, see below for some minor stuff while others have the chance
to further review this.
I'm ok with how it is right now, not being that versed into JSON
details.
Do you plan to output the headers too? I think we should, for
co
or all sessions when SIGCHLD
> is received, to make sure we don't miss any session exit.
>
> Also fix close condition for signal_fd.
Thanks, applied.
- Arnaldo
> Reported-by: Ian Rogers
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c | 50 +++
gt; > 8027742,,cycles,8013344503,100.00,0.001,GHz
> > 2871717,,instructions,8013356501,100.00,0.36,insn per cycle
> > 553564,,branches,8013366204,100.00,69.081,K/sec
> > 54021,,branch-misses,8013375952,100.00,9.76,of all branches
> >
> > Signed-off-by: Jin Yao
>
> LGTM, for patchset:
>
> Acked-by: Jiri Olsa
After doing the s/cvs/csv/ changes, applied.
- Arnaldo
Em Wed, Mar 24, 2021 at 10:12:43AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Mar 24, 2021 at 10:05:18AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Mar 19, 2021 at 03:01:56PM +0800, Jin Yao escreveu:
> > > The patch "perf stat: Align CSV output fo
Em Wed, Mar 24, 2021 at 10:05:18AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Mar 19, 2021 at 03:01:56PM +0800, Jin Yao escreveu:
> > The patch "perf stat: Align CSV output for summary mode" aligned
> > CVS output and added "summary" to the first column
d to the CVS output.
>
> If we set '--no-cvs-summary' option, the "summary" string would
> not be added, also check with this case.
You mixed up cvs with csv in various places, I'm fixing it up...
- Arnaldo
> Signed-off-by: Jin Yao
> ---
> v3:
Em Fri, Mar 19, 2021 at 04:14:42PM +, Song Liu escreveu:
> > On Mar 19, 2021, at 8:58 AM, Namhyung Kim wrote:
> > On Sat, Mar 20, 2021 at 12:35 AM Arnaldo Carvalho de Melo
> > wrote:
> >> Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu:
> >&
Em Tue, Mar 23, 2021 at 02:59:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Mar 23, 2021 at 05:10:10PM +0100, Ingo Molnar escreveu:
> >
> > Here's the delta between -v1 and -v2, in case you already have -v1 or
> > want to review the changes only:
>
> I
Em Tue, Mar 23, 2021 at 09:37:42AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Mar 23, 2021 at 09:25:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Mar 19, 2021 at 03:41:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Mar 18, 2021 at 10:15:13P
,
> },
> };
>
> @@ -258,6 +264,11 @@ static int __test__bpf(int idx)
> ret = do_test(obj,
> bpf_testcase_table[idx].target_func,
> bpf_testcase_table[idx].expect_result);
> + if (bpf_testcase_table
Em Tue, Mar 23, 2021 at 05:10:10PM +0100, Ingo Molnar escreveu:
>
> Here's the delta between -v1 and -v2, in case you already have -v1 or
> want to review the changes only:
I had not pushed out it, so I just replaced v1 with v2, thanks.
- Arnaldo
> ---
> tools/perf/arch/arm64
Em Sun, Mar 21, 2021 at 12:37:34PM +0100, Ingo Molnar escreveu:
>
> Fix ~81 single-word typos in the perf tooling code - accumulated over the
> years.
Thanks, applied.
- Arnaldo
> Signed-off-by: Ingo Molnar
> ---
> tools/perf/Documentation/perf-buildid-cache.txt |
Em Tue, Mar 23, 2021 at 09:25:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Mar 19, 2021 at 03:41:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Mar 18, 2021 at 10:15:13PM +0100, Jiri Olsa escreveu:
> > > On Tue, Mar 16, 2021 at 02:18:35PM -07
Em Fri, Mar 19, 2021 at 03:41:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Mar 18, 2021 at 10:15:13PM +0100, Jiri Olsa escreveu:
> > On Tue, Mar 16, 2021 at 02:18:35PM -0700, Song Liu wrote:
> > > bperf is off by default. To enable it, pass --bpf-counters option
tch in the series I'm getting this
after a 'make -C tools/ clean', now I'm checking if I need some new
clang, ideas?
- Arnaldo
[acme@quaco perf]$ make O=/tmp/build/perf -C tools/perf BUILD_BPF_SKEL=1
PYTHON=python3 install-bin
make: Entering directory '/home/acme/git/perf/tools/perf'
BUILD:
ow)
> url: [https://docs.microsoft.com/en-us/cpp/code-quality/c6328?view=msvc-160]
> url: [https://stackoverflow.com/questions/122721]
tools/ and the kernel versions of isspace are implemented in
include/linux/ctype.h and tools/include/linux/ctype.h.
- Arnaldo
> Signed-off-by: SeungHoo
Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu:
> On Fri, Mar 19, 2021 at 9:22 AM Song Liu wrote:
> > > On Mar 18, 2021, at 5:09 PM, Arnaldo wrote:
> > > On March 18, 2021 6:14:34 PM GMT-03:00, Jiri Olsa
> > > wrote:
> > >> On Thu,
On March 18, 2021 6:14:34 PM GMT-03:00, Jiri Olsa wrote:
>On Thu, Mar 18, 2021 at 03:52:51AM +, Song Liu wrote:
>>
>>
>> > On Mar 17, 2021, at 6:11 AM, Arnaldo Carvalho de Melo
> wrote:
>> >
>> > Em Wed, Mar 17, 2021 at 02:29:28P
Em Thu, Mar 18, 2021 at 01:16:37PM +0100, Jiri Olsa escreveu:
> On Wed, Mar 17, 2021 at 10:42:45AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Mar 17, 2021 at 08:17:52PM +0800, Jin, Yao escreveu:
> > > I'm OK to only support 'cpu_core/cpu-cycles/' or 'c
added to the csets I had applied already in my local repo.
- Arnaldo
fix the default then. Jin, can you please consider
adding a 'perf test' shell entry to parse the CSV mode with/without that
summary? This way we'll notice when the new normal gets broken.
- Arnaldo
id platform, user may only want to enable the LLC-loads on core CPUs
> or on atom CPUs. That's reasonable. While if we don't support the pmu style
> event, how to satisfy this requirement?
>
> If we can support the pmu style event, we can also use the same way for
> cpu_core/cycles/. At least it's not a bad thing, right? :)
While we're discussing, do we really want to use the "core" and "atom"
terms here? I thought cpu/cycles/ would be ok for the main (Big) CPU and
that we should come up with some short name for the "litle" CPUs.
Won't we have the same situation with ARM where we want to know the
number of cycles spent on a BIG core and also on a little one?
Perhaps 'cycles' should mean all cycles, and then we use 'big/cycles/' and
'little/cycles/'?
- Arnaldo
it it so it doesn't
> flood dmesg? Then the user will know what's going on, and may
> choose to temporarily disable C-states using the 'cpupower' tool.
Would be interesting as well to make 'perf top' realize that somehow
(looking at some cpu id, etc) and don't use IBS when C-states are being
used and/or warn the user about the situation, i.e. cycles:P can't be
used in this machine if C-states are enabled?
- Arnaldo
0 || ena == 0 || counter->counts->scaled == -1) {
> if (config->metric_only) {
> pm(config, , NULL, "", "", 0);
> diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
> index 41107b8deac5..def0cdc84133 100644
> --- a/tools/perf/util/stat.h
> +++ b/tools/perf/util/stat.h
> @@ -128,6 +128,7 @@ struct perf_stat_config {
> bool all_user;
> bool percore_show_thread;
> bool summary;
> + bool no_cvs_summary;
> bool metric_no_group;
> bool metric_no_merge;
> bool stop_read_counter;
> @@ -160,6 +161,7 @@ struct perf_stat_config {
> };
>
> void perf_stat__set_big_num(int set);
> +void perf_stat__set_no_cvs_summary(int set);
>
> void update_stats(struct stats *stats, u64 val);
> double avg_stats(struct stats *stats);
> --
> 2.17.1
>
--
- Arnaldo
instructions are added when sharing using
--bpf-counters?
I.e. compare the "expensive time multiplexing of events" with its
avoidance by using --bpf-counters.
Song, have you perfmormed such measurements?
- Arnaldo
> Thanks,
> Namhyung
>
> >
> > bperf tries to redu
break existing scripts.
Can we do this with a new option?
I.e. like --cvs-summary?
- Arnaldo
ds to
info->jited_ksyms == NULL. In order to solve this problem, Add a
check before use.
Also plug some leaks on the error path.
> Suggested-by: Jiri Olsa
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: A
-by: Yang Jihong
Please take a look at Documentation/process/submitting-patches.rst.
Regards,
- Arnaldo
> ---
> tools/perf/builtin-annotate.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builti
ist has a reference to it, if it is
removed outside the __dsos__add(), then list traversal may be corrupted.
> > if dso is not stored elsewhere so we want dsos__exit to
> > release it.. but it's still stored in map object
> >
> > I checked and we do extra dso__get in machine__findnew_vdso
> > (and also in dsos__findnew_id) ... so that one seems to me
> > like the one we should remove
findnew _needs_ to grab te refcount while holding the lock, so that what
it returns won't go away in a different thread.
> > but I might be missing something, I'll try to check more
> > deeply later on
> I think we assume the find/findnew APIs include increment of
> the refcount, otherwise all callers should be converted to do it
> explicitly.
The callers can't grab the reference safely, i.e. its outside the lock.
> Then the 'find' part should increase it but the 'new' part is not
> (as it already has 2) and that's why we have that.
>
> Thanks,
> Namhyung
--
- Arnaldo
1.2.pdf
>
> The PMU events described in above document seems to work well
> with this patch!
> Please feel free to add:
>
> Tested-by: Masayoshi Mizuma
Thanks, applied.
- Arnaldo
> Thanks!
> Masa
>
> >
> > Signed-off-by: Shunsuke Nakamura
>
Em Wed, Mar 10, 2021 at 12:38:02PM +0100, Jiri Olsa escreveu:
> On Wed, Mar 10, 2021 at 01:11:38PM +0800, Jin Yao wrote:
> > Warnings are reported for invalid bits.
> >
> > Co-developed-by: Jiri Olsa
> > Signed-off-by: Jin Yao
>
> Reviewed-by: Jiri Olsa
Thanks, applied.
- Arnaldo
Em Fri, Mar 12, 2021 at 06:52:39PM +, Song Liu escreveu:
> > On Mar 12, 2021, at 6:24 AM, Arnaldo Carvalho de Melo
> > wrote:
> > Em Thu, Mar 11, 2021 at 06:02:57PM -0800, Song Liu escreveu:
> >> perf uses performance monitoring counters (PMCs) to monitor system
Em Fri, Mar 12, 2021 at 04:07:42PM +, Song Liu escreveu:
>
>
> > On Mar 12, 2021, at 6:24 AM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Thu, Mar 11, 2021 at 06:02:57PM -0800, Song Liu escreveu:
> >> perf uses performance monitoring counters (P
fig stat.bpf-counters=yes
That would make 'perf stat' use BPF counters for what it can, using the
default method for the non-supported targets, emitting some 'perf stat
-v' visible warning (i.e. a debug message), i.e. make it opt-in that the
user wants to use BPF counters for all that is possible at t
t; Acked-by: Jiri Olsa
That is really old:
Fixes: 1a853e36871b533c ("perf record: Allow specifying a pid to record")
Circa 2009, the PERF_RECORD_COMM is ok as TASK_COMM_LEN is 16.
But I think there are other places synthesizing PERF_RECORD_MMAP,
jitdump maybe:
tools/perf/bench/inject-buildid.c, but it uses memset to zero the whole
union, no problem.
tools/perf/util/jitdump.c
jit_repipe_code_load() but it uses calloc to allocate the union
perf_event, so no problem as well.
Thanks, applied.
- Arnaldo
t just s/390, it is entirely possible that that
variable gets used with an undefined value.
- Arnaldo
> Output after:
> [root@m35lp76 perf]# make util/synthetic-events.o
>
> CC util/synthetic-events.o
> [root@m35lp76 perf]#
>
> Signed-off-by: Thomas Richter
>
1 - 100 of 34313 matches
Mail list logo
