linux-kernel.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).