linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: "William Cohen" <wcohen@redhat.com>,
	"linux-perf-use." <linux-perf-users@vger.kernel.org>,
	大平怜 <rei.odaira@gmail.com>,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: Issue perf attaching to processes creating many short-live threads
Date: Mon, 26 Oct 2015 16:49:33 -0300	[thread overview]
Message-ID: <20151026194933.GS27006@kernel.org> (raw)
In-Reply-To: <562A8C0F.4090607@gmail.com>

Em Fri, Oct 23, 2015 at 01:35:43PM -0600, David Ahern escreveu:
> I was referring to something like 'make -j 1024' on a large system (e.g.,
> 512 or 1024 cpus) and then starting perf. This is the same problem you are
> describing -- lot of short lived processes. I am fairly certain I described
> the problem on lkml or perf mailing list. Not even the task_diag proposal
> (task_diag uses netlink to push task data to perf versus walking /proc) has
> a chance to keep up.

Yeah, to get info about existing threads (its maps, comm, etc) you would
pretty much have to stop the world, collect the info, then let
everything go back running because then new threads would insert the
PERF_RECORD_{FORK,COMM,MMAP,etc} records in the ring buffer.

I think we need an option to say: don't try to find info about existing
threads, i.e. don't look at /proc at all, we would end up with samples
being attributed to a pid/tid and that would be it, should be useful for
some use cases, no?

- Arnaldo

  reply	other threads:[~2015-10-26 19:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 18:52 Issue perf attaching to processes creating many short-live threads William Cohen
2015-10-23 18:56 ` David Ahern
2015-10-23 19:27   ` William Cohen
2015-10-23 19:35     ` David Ahern
2015-10-26 19:49       ` Arnaldo Carvalho de Melo [this message]
2015-10-26 21:42         ` David Ahern
2015-10-27 12:33           ` Arnaldo Carvalho de Melo
2015-10-27 14:15             ` David Ahern
2015-10-27 14:47               ` Arnaldo Carvalho de Melo

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=20151026194933.GS27006@kernel.org \
    --to=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=oprofile-list@lists.sourceforge.net \
    --cc=rei.odaira@gmail.com \
    --cc=wcohen@redhat.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 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).