From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Borislav Petkov <bp@suse.de>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
David Ahern <dsahern@gmail.com>, Don Zickus <dzickus@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Jean Pihet <jean.pihet@linaro.org>,
Mike Galbraith <efault@gmx.de>,
Namhyung Kim <namhyung@kernel.org>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Stephane Eranian <eranian@google.com>
Subject: Re: [RFC 00/14] perf pollfd v3
Date: Thu, 11 Sep 2014 13:33:36 +0200 [thread overview]
Message-ID: <20140911113336.GB13634@krava.brq.redhat.com> (raw)
In-Reply-To: <1410358129-9965-1-git-send-email-acme@kernel.org>
On Wed, Sep 10, 2014 at 11:08:35AM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> Hi,
>
> Main different to what was discussed in v2[1]:
>
> Poll all event file descriptors, not just the ones mmaped.
>
> This is a bug that was present before, noticed by Adrian Hunter while
> reviewing this patchkit, i.e. we were polling just the mmaped ones, because
> then we would look at all the ring buffers when just one of the polled
> descriptors was ready to read.
>
> But this could lead to delays in polling when one of the mmaped fds was
> closed and we would then not be notified when another, associated to it by
> means of PERF_EVENT_IOC_SET_OUTPUT, had events available.
>
> Also refcount the mmaps associated by means of PERF_EVENT_IOC_SET_OUTPUT,
> so that we can properly unmap a ring buffer to which all its file descriptors
> had been closed, for longer running apps.
>
> It is all available on my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/fdarray.v2
>
> I kept the v3 for the series as I initially called it pollfd, but since the
> class that grew out of it was named fdarray, thus the fdarray.v2 branch name.
>
> Please let me know if there are still any other problems, now back to
> fixing up my last perf/core pull req wrt those external proggies problems.
>
hum got this one:
[jolsa@krava perf]$ ./perf record ls
Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cycles).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EVENTS=y kernel support configured?
*** Error in `./perf': free(): invalid next size (fast): 0x00000000020d2290 ***
*** Error in `./perf': malloc(): memory corruption: 0x00000000020d22b0 ***
[jolsa@krava perf]$ pstack 20706
#0 pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:94
#1 0x0000003408109d1c in __GI___backtrace (array=array@entry=0x7fff5c073d60, size=size@entry=64) at ../sysdeps/x86_64/backtrace.c:103
#2 0x0000003408075d34 in __libc_message (do_abort=2, fmt=fmt@entry=0x340817e568 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:176
#3 0x000000340807e21c in malloc_printerr (ptr=0x20d22b0, str=0x340817bcbf "malloc(): memory corruption", action=<optimized out>) at malloc.c:4937
#4 _int_malloc (av=0x34083ba780 <main_arena>, bytes=56) at malloc.c:3411
#5 0x000000340808002c in __GI___libc_malloc (bytes=56) at malloc.c:2863
#6 0x0000003407c0d379 in _dl_map_object_deps (map=map@entry=0x7fe140d0ba18, preloads=preloads@entry=0x0, npreloads=npreloads@entry=0, trace_mode=trace_mode@entry=0, open_mode=open_mode@entry=-2147483648) at dl-deps.c:515
#7 0x0000003407c138bc in dl_open_worker (a=a@entry=0x7fff5c0748f8) at dl-open.c:265
#8 0x0000003407c0f304 in _dl_catch_error (objname=objname@entry=0x7fff5c0748e8, errstring=errstring@entry=0x7fff5c0748f0, mallocedp=mallocedp@entry=0x7fff5c0748e0, operate=operate@entry=0x3407c13740 <dl_open_worker>, args=args@entry=0x7fff5c0748f8) at dl-error.c:177
#9 0x0000003407c131eb in _dl_open (file=0x340817aaa6 "libgcc_s.so.1", mode=-2147483647, caller_dlopen=0x3408109c05 <init+21>, nsid=-2, argc=3, argv=<optimized out>, env=0x20ae470) at dl-open.c:656
#10 0x00000034081305d2 in do_dlopen (ptr=ptr@entry=0x7fff5c074b00) at dl-libc.c:87
#11 0x0000003407c0f304 in _dl_catch_error (objname=0x7fff5c074ae0, errstring=0x7fff5c074af0, mallocedp=0x7fff5c074ad0, operate=0x3408130590 <do_dlopen>, args=0x7fff5c074b00) at dl-error.c:177
#12 0x0000003408130692 in dlerror_run (args=0x7fff5c074b00, operate=0x3408130590 <do_dlopen>) at dl-libc.c:46
#13 __GI___libc_dlopen_mode (name=name@entry=0x340817aaa6 "libgcc_s.so.1", mode=mode@entry=-2147483647) at dl-libc.c:163
#14 0x0000003408109c05 in init () at ../sysdeps/x86_64/backtrace.c:52
#15 0x0000003408c0ca40 in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:103
#16 0x0000003408109d1c in __GI___backtrace (array=array@entry=0x7fff5c074dc0, size=size@entry=64) at ../sysdeps/x86_64/backtrace.c:103
#17 0x0000003408075d34 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x340817e568 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:176
#18 0x000000340807d0b8 in malloc_printerr (ptr=<optimized out>, str=0x340817e690 "free(): invalid next size (fast)", action=3) at malloc.c:4937
#19 _int_free (av=0x34083ba780 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3789
#20 0x0000000000465e72 in perf_evsel__free_fd (evsel=0x20af190) at util/evsel.c:786
#21 perf_evsel__close (evsel=evsel@entry=0x20af190, ncpus=<optimized out>, nthreads=nthreads@entry=1) at util/evsel.c:1139
#22 0x000000000045f77d in perf_evlist__close (evlist=0x20ae8b0) at util/evlist.c:1148
#23 perf_evlist__delete (evlist=0x20ae8b0) at util/evlist.c:114
#24 0x000000000042b878 in cmd_record (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin-record.c:967
#25 0x000000000041c455 in run_builtin (p=p@entry=0x815e70 <commands+144>, argc=argc@entry=2, argv=argv@entry=0x7fff5c077c50) at perf.c:331
#26 0x000000000041bc70 in handle_internal_command (argv=0x7fff5c077c50, argc=2) at perf.c:390
#27 run_argv (argv=0x7fff5c0779d0, argcp=0x7fff5c0779dc) at perf.c:434
#28 main (argc=2, argv=0x7fff5c077c50) at perf.c:549
jirka
next prev parent reply other threads:[~2014-09-11 11:34 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 14:08 Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 01/14] perf evlist: Introduce perf_evlist__filter_pollfd method Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 02/14] perf tests: Add test for perf_evlist__filter_pollfd() Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 03/14] perf evlist: Monitor POLLERR and POLLHUP events too Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 04/14] perf evlist: We need to poll all event file descriptors Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 05/14] perf record: Filter out POLLHUP'ed " Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 06/14] perf trace: " Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 07/14] perf evlist: Allow growing pollfd on add method Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 08/14] perf tests: Add pollfd growing test Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 09/14] perf kvm stat live: Use perf_evlist__add_pollfd() instead of local equivalent Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 10/14] perf evlist: Introduce poll method for common code idiom Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 11/14] tools lib api: Adopt fdarray class from perf's evlist Arnaldo Carvalho de Melo
2014-09-11 15:09 ` [PATCH] tools lib fd array: Do not set fd as non blocking evlist Jiri Olsa
2014-09-11 15:27 ` Arnaldo Carvalho de Melo
2014-09-11 15:53 ` Arnaldo Carvalho de Melo
2014-09-12 12:58 ` [PATCH 11/14] tools lib api: Adopt fdarray class from perf's evlist Jiri Olsa
2014-09-12 13:44 ` Arnaldo Carvalho de Melo
2014-09-12 14:16 ` Jiri Olsa
2014-09-12 14:22 ` Arnaldo Carvalho de Melo
2014-09-12 16:54 ` Borislav Petkov
2014-09-12 20:48 ` Arnaldo Carvalho de Melo
2014-09-12 22:12 ` Borislav Petkov
2014-09-22 12:29 ` Jiri Olsa
2014-09-10 14:08 ` [PATCH 12/14] perf evlist: Refcount mmaps Arnaldo Carvalho de Melo
2014-09-10 14:08 ` [PATCH 13/14] tools lib fd array: Allow associating an integer cookie with each entry Arnaldo Carvalho de Melo
2014-09-11 10:33 ` Jiri Olsa
2014-09-11 13:29 ` Arnaldo Carvalho de Melo
2014-09-11 14:59 ` Jiri Olsa
2014-09-11 15:23 ` Arnaldo Carvalho de Melo
2014-09-11 15:35 ` Jiri Olsa
2014-09-11 15:49 ` Arnaldo Carvalho de Melo
2014-09-11 16:07 ` Jiri Olsa
2014-09-10 14:08 ` [PATCH 14/14] perf evlist: Unmap ring buffer when fd is nuked Arnaldo Carvalho de Melo
2014-09-11 12:27 ` Jiri Olsa
2014-09-11 13:40 ` Arnaldo Carvalho de Melo
2014-09-11 11:33 ` Jiri Olsa [this message]
2014-09-11 11:48 ` [RFC 00/14] perf pollfd v3 Jiri Olsa
2014-09-11 13:30 ` Arnaldo Carvalho de Melo
2014-09-11 21:36 ` Arnaldo Carvalho de Melo
2014-09-18 16:04 ` Arnaldo Carvalho de Melo
2014-09-22 13:35 ` Jiri Olsa
2014-09-22 14:49 ` Arnaldo Carvalho de Melo
2014-09-22 14:51 ` Jiri Olsa
2014-09-22 21:10 ` Arnaldo Carvalho de Melo
2014-09-23 9:26 ` Jiri Olsa
2014-09-23 12:46 ` Arnaldo Carvalho de Melo
2014-09-23 12:52 ` Jiri Olsa
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=20140911113336.GB13634@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=bp@suse.de \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=dsahern@gmail.com \
--cc=dzickus@redhat.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jean.pihet@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
/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
all inboxes | Powered by JetHome®