mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome