public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>
Subject: Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads
Date: Mon, 1 Feb 2021 21:32:50 +0100	[thread overview]
Message-ID: <YBhlcmCH2K3lI/YJ@krava> (raw)
In-Reply-To: <CAM9d7cj7E1u73ExFstFgQ9JMOFGM2KSrZs0zyUKte-C4VdBOjg@mail.gmail.com>

On Mon, Feb 01, 2021 at 01:54:32PM +0900, Namhyung Kim wrote:
> On Mon, Feb 1, 2021 at 7:48 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Fri, Jan 29, 2021 at 02:49:00PM +0900, Namhyung Kim wrote:
> > > To synthesize information to resolve sample IPs, it needs to scan task
> > > and mmap info from the /proc filesystem.  For each process, it
> > > opens (and reads) status and maps file respectively.  But as kernel
> > > threads don't have memory maps so we can skip the maps file.
> > >
> > > To find kernel threads, check "VmPeak:" line in /proc/<PID>/status
> > > file.  It's about the peak virtual memory usage so only user-level
> > > tasks have that.  Also check "Threads:" line (which follows the VmPeak
> > > line whether or not it exists) to be sure it's read enough data - just
> > > in case of deeply nested pid namespaces or large number of
> > > supplementary groups are involved.
> >
> > I don't understand this Threads: check, could you please
> > show example where it's useful for the check?
> 
> Sure!
> 
> I think there's a chance that the status file actually has the VmPeak line,
> but it didn't read to the line for some reason.  In that case, we should
> not assume the task is a kernel thread.
> 
> So it needs to make sure whether there's no such line in the file
> or it just didn't read enough data.  To check the latter case, it
> searches the "Threads" line which follows the VmPeak always.

ah ok, there's limited buffer for the status file

we could call filename__read_str to read the whole file
and skip these checks.. but perhaps that'd be another
slowdown you trying to prevent

if you put that comment to the code, I'm ok with that

thanks,
jirka


  reply	other threads:[~2021-02-01 20:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29  5:48 [PATCH v2 0/3] perf tools: Minor improvements in event synthesis Namhyung Kim
2021-01-29  5:48 ` [PATCH 1/3] perf tools: Use /proc/<PID>/task/<TID>/status for synthesis Namhyung Kim
2021-01-31 23:00   ` Jiri Olsa
2021-02-01  4:41     ` Namhyung Kim
2021-02-01 20:41       ` Jiri Olsa
2021-01-29  5:49 ` [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads Namhyung Kim
2021-01-31 22:48   ` Jiri Olsa
2021-02-01  4:54     ` Namhyung Kim
2021-02-01 20:32       ` Jiri Olsa [this message]
2021-01-29  5:49 ` [PATCH 3/3] perf tools: Use scandir() to iterate threads Namhyung Kim
2021-01-31 22:35 ` [PATCH v2 0/3] perf tools: Minor improvements in event synthesis Jiri Olsa
2021-02-01  4:35   ` Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2021-02-02  9:01 [PATCHSET v3 " Namhyung Kim
2021-02-02  9:01 ` [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads Namhyung Kim
2020-12-21  7:00 [PATCH 0/3] perf tools: Minor improvements in event synthesis Namhyung Kim
2020-12-21  7:00 ` [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads Namhyung Kim
2020-12-28 11:50   ` Jiri Olsa
2020-12-29  5:35     ` Namhyung Kim

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=YBhlcmCH2K3lI/YJ@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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