All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: chenggang qin <chenggang.qin@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	acme@ghostprotocols.net, namhyung.kim@lge.com,
	a.p.zijlstra@chello.nl, paulus@samba.org, nelhage@nelhage.com
Subject: Re: [PATCH]Perf top:  Add ability to detect new threads dynamically during 'perf top -p 'pid'' is running
Date: Tue, 04 Sep 2012 10:00:20 -0600	[thread overview]
Message-ID: <50462594.7080204@gmail.com> (raw)
In-Reply-To: <5034EE98.3070406@gmail.com>

On 8/22/12 8:37 AM, chenggang qin wrote:
> From: Chenggang Qin <chenggang.qin@gmail.com>
> 
> While we use "perf top -p 'pid'" to monitor the symbols of specified
> processes, some new threads would be created by the monitored processes
> during "perf top" is running. In current version, these new threads and
> their symbols cannot be shown.
> This patch add ability to show these new threads.
> 
> Signed-off-by: Chenggang Qin <chenggang.qcg@taobao.com>
> 
> ---
>   tools/perf/builtin-top.c |   86 ++++++++++++++++++++++++++++++++++++++++++++--
>   tools/perf/util/evlist.c |    2 ++
>   2 files changed, 85 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index 68cd61e..54c9cc1 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -882,7 +882,7 @@ static void perf_top__mmap_read(struct perf_top *top)
>   		perf_top__mmap_read_idx(top, i);
>   }
>   
> -static void perf_top__start_counters(struct perf_top *top)
> +static int perf_top__start_counters(struct perf_top *top)
>   {
>   	struct perf_evsel *counter, *first;
>   	struct perf_evlist *evlist = top->evlist;
> @@ -929,6 +929,10 @@ try_again:
>   				     group_fd) < 0) {
>   			int err = errno;
>   
> +			if (err == ESRCH) {
> +				return err;
> +			}
> +
>   			if (err == EPERM || err == EACCES) {
>   				ui__error_paranoid();
>   				goto out_err;
> @@ -994,7 +998,7 @@ try_again:
>   		goto out_err;
>   	}
>   
> -	return;
> +	return 0;
>   
>   out_err:
>   	exit_browser(0);
> @@ -1018,6 +1022,77 @@ static int perf_top__setup_sample_type(struct perf_top *top)
>   	return 0;
>   }
>   
> +static int thread_map_cmp(struct thread_map *threads_a,
> +			  struct thread_map *threads_b)
> +{
> +	int i, j;
> +
> +	if (threads_a->nr != threads_b->nr) {
> +		return 1;
> +	} else {
> +		for (i = 0; i < threads_b->nr; i++) {
> +			for (j = 0; j < threads_a->nr; j++)
> +				if (threads_b->map[i] == threads_a->map[j])
> +					break;
> +
> +			if (j == threads_a->nr)
> +				return 1;
> +		}
> +
> +		return 0;
> +	}
> +}
> +
> +static void check_new_threads(struct perf_top *top)
> +{
> +	struct thread_map *new_thread_map;
> +	struct perf_evsel *counter;
> +	struct perf_evlist *evlist = top->evlist;
> +
> +retry:
> +	new_thread_map = thread_map__new_str(top->target.pid, top->target.tid,
> +					     top->target.uid);
> +	if (!new_thread_map)
> +		return;
> +
> +	if (thread_map_cmp(top->evlist->threads, new_thread_map) == 0) {
> +		free(new_thread_map);
> +		return;
> +	} else {
> +		list_for_each_entry(counter, &evlist->entries, node) {
> +			perf_evsel__close(counter, top->evlist->cpus->nr,
> +					  top->evlist->threads->nr);
> +		}
> +
> +		if (top->evlist->mmap)
> +			perf_evlist__munmap(top->evlist);
> +
> +		if (top->evlist->pollfd) {
> +			free(top->evlist->pollfd);
> +			top->evlist->pollfd = NULL;
> +		}
> +
> +		top->evlist->nr_fds = 0;
> +
> +		thread_map__delete(top->evlist->threads);
> +		top->evlist->threads = new_thread_map;
> +
> +		if (perf_top__start_counters(top) == ESRCH) {
> +			while (thread_map_cmp(top->evlist->threads,
> +					      new_thread_map) == 0) {
> +				new_thread_map = thread_map__new_str(top->target.pid,
> +								     top->target.tid,
> +								     top->target.uid);
> +				if (!new_thread_map)
> +					return;
> +			}
> +			goto retry;
> +		}
> +
> +		return;
> +	}
> +}
> +

I think it would be better to respond to FORK (and EXIT) events and open
(close) counters accordingly. perf-top gets events when a thread is
created or terminated; it might as well use the events to react than to
poll every trip through the loop.

David

      reply	other threads:[~2012-09-04 16:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 14:37 [PATCH]Perf top: Add ability to detect new threads dynamically during 'perf top -p 'pid'' is running chenggang qin
2012-09-04 16:00 ` David Ahern [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=50462594.7080204@gmail.com \
    --to=dsahern@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=chenggang.qin@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung.kim@lge.com \
    --cc=nelhage@nelhage.com \
    --cc=paulus@samba.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 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.