All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Specifying some processes to record using perf
Date: Sun, 05 Feb 2012 10:47:22 -0700	[thread overview]
Message-ID: <4F2EC0AA.2090706@gmail.com> (raw)
In-Reply-To: <20120205142349.GE30158@infradead.org>


On 02/05/2012 07:23 AM, Arnaldo Carvalho de Melo wrote:
> Em Sat, Feb 04, 2012 at 04:19:59PM -0700, David Ahern escreveu:
>> On 02/02/2012 09:33 AM, David Ahern wrote:
>>>
>>> On 02/02/2012 08:52 AM, Jean-Michel Hautbois wrote:
>>>> Hi all,
>>>>
>>>> I am using perf and I have several process and threads to record.
>>>> I know that some threads in particular are interesting, and I don't
>>>> find a way to specify multiple threads in perf record.
>>>> The "-t" option takes only one thread IIUC.
>>
>> Found some time on the plane ride home to give this a shot. The attached
>> applies on top of the perf/core branch in:
>>
>>     git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>>
>> You can specify multiple threads or multiple processing using a
>> comma-separated list. e.g., -t tid1,tid2,... or -p pid1,pid2,... (not both).
>>
>> It still needs more testing, but let me know how it works for what you need.
>>
>> Arnaldo: would you mind scanning this and see if there are any major
>> problems/objections with the approach?
> 
> It looks ok, but I wouldn't remove the existing specialized thread_map
> constructors, i.e. no need to first transform getpid() into an string to
> then pass to a generic constructor that would then back convert it into
> a pid_t :-)

Only perf-test does that; all the rest take pid/tid from the user.

> 
> Just add new constructors for CSV strings, like:
> 
> struct thread_map *thread_map__new_by_pids(const char *pid_list);
> 
> struct thread_map *thread_map__new_by_tids(const char *pid_list);
> 
> with the expected results, i.e. they would just tokenize and call the
> more basic constructors, at least in the by_pids, then concatenating the
> results, etc.

Ok. I can leave the existing ones. I did not want that interface to get
too complicated; with this change it will be easy to remove the 'or' and
allow a user to specify multiple thread ids and multiple process ids.

David

      reply	other threads:[~2012-02-05 17:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAL8zT=gX5=S9fd1MdYyYVYg+35anmK-aJwFj9fUiKNuMSb8n_w@mail.gmail.com>
2012-02-02 15:52 ` Specifying some processes to record using perf Jean-Michel Hautbois
2012-02-02 16:33   ` David Ahern
2012-02-04 23:19     ` David Ahern
2012-02-05 14:23       ` Arnaldo Carvalho de Melo
2012-02-05 17:47         ` 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=4F2EC0AA.2090706@gmail.com \
    --to=dsahern@gmail.com \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.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.