From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: kan.liang@intel.com
Cc: linux-kernel@vger.kernel.org, ying.huang@intel.com, andi@firstfloor.org
Subject: Re: [PATCH V2 1/1] perf,tools: add time out to force stop endless mmap processing
Date: Thu, 11 Jun 2015 12:45:44 -0300 [thread overview]
Message-ID: <20150611154544.GB3195@kernel.org> (raw)
In-Reply-To: <1434008944-10042-1-git-send-email-kan.liang@intel.com>
Em Thu, Jun 11, 2015 at 03:49:04AM -0400, kan.liang@intel.com escreveu:
> perf top reads all threads' /proc/xxx/maps. If there is any threads
> which generating a keeping growing huge /proc/xxx/maps, perf will do
> infinite loop in perf_event__synthesize_mmap_events.
> This patch fixes this issue by adding a time out to force stop this kind
> of endless mmap processing.
>
> Reported-by: Huang, Ying <ying.huang@intel.com>
> Signed-off-by: Kan Liang <kan.liang@intel.com>
>
> ---
>
> Changes since V1
> - Add warning message for time out.
<SNIP>
> + if ((rdclock() - t) > MMAP_TIMEOUT) {
> + pr_warning("Reading %s time out."
> + "The file may be too huge or keep growing.\n",
> + filename);
> + break;
> + }
> +
> /* ensure null termination since stack will be reused. */
> strcpy(execname, "");
Have you tried this? I.e. pr_warning, IIRC, will make it appear in the
logs that this happened, but this will get probably lost in the noise
and only if you have a suspicion that something may have went wrong you
will try to look in the, possibly long, logs for a possible explanation.
So, perhaps we need to do something like what is done in
perf_session__process_events(), i.e. at the end of the synthesizing,
look at a counter for such situations and use ui__warning(), that in the
TUI case will show a window message that will show the warning and wait
for the user to acknowledge it by pressing a Ok button.
This is all done in perf_session__warn_about_errors().
This is how I think this should be done, but as this is such a corner
case, and this patch fixes these long loops, this may be applied now and
then what I suggest may be done on top.
Anyway, please try to reply to David Ahern question about an example for
this case, because he is working on a netlink based replacement to the
synthesizing of PERF_RECORD_ events for existing tasks and will have to
take this case into account there as well...
- Arnaldo
prev parent reply other threads:[~2015-06-11 15:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 7:49 [PATCH V2 1/1] perf,tools: add time out to force stop endless mmap processing kan.liang
2015-06-11 15:45 ` Arnaldo Carvalho de Melo [this message]
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=20150611154544.GB3195@kernel.org \
--to=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ying.huang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.