All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Mike Galbraith <efault@gmx.de>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf record: mmap output file - v2
Date: Tue, 15 Oct 2013 08:02:00 +0200	[thread overview]
Message-ID: <20131015060200.GA3866@gmail.com> (raw)
In-Reply-To: <1381805731-10398-1-git-send-email-dsahern@gmail.com>


* David Ahern <dsahern@gmail.com> wrote:

> +	/* for MMAP based file writes */
> +	void			*mmap_addr;
> +	u64			bytes_at_mmap_start; /* bytes in file when mmap use starts */
> +	u64			mmap_offset;    /* current location within mmap */
> +	size_t			mmap_size;      /* size of mmap segments */
> +	bool			use_mmap;

> +	if (!rec->opts.pipe_output && stat(output_name, &st) == 0) {
> +		rec->use_mmap = true;
> +		rec->bytes_at_mmap_start = st.st_size - rec->bytes_written;
> +	}

1)

I think __cmd_record() has become way too large, nearly 300 lines of code. 
It would be nice to split it into 2-3 helpers that operate on 'struct 
perf_record' or so.

2)

The stat() seems superfluous, here in __cmd_record() we've just checked 
the output_name and made sure it exists. Can that stat() call ever fail?

3)

The rec->bytes_at_mmap_start field feels a bit weird. If I read the code 
correctly, in every 'perf record' invocation, rec->bytes_written starts at 
0 - i.e. we don't have repeat invocations of cmd_record().

That means that this:

		rec->bytes_at_mmap_start = st.st_size - rec->bytes_written;

is really:

		rec->bytes_at_mmap_start = st.st_size;

furthermore, since we don't allow appends anymore, st.st_size ought to be 
zero as well.

Which means that ->bytes_at_mmap_start is always zero - and could be 
eliminated altogether.

Thanks,

	Ingo

  reply	other threads:[~2013-10-15  6:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15  2:55 [PATCH] perf record: mmap output file - v2 David Ahern
2013-10-15  6:02 ` Ingo Molnar [this message]
2013-10-15  7:09   ` Namhyung Kim
2013-10-15  7:25     ` Ingo Molnar
2013-10-15  8:17       ` Namhyung Kim
2013-10-15 12:22       ` Jiri Olsa
2013-10-15 13:20         ` Ingo Molnar
2013-10-15 13:25     ` David Ahern
2013-10-16  1:24       ` Namhyung Kim
2013-10-15  7:31 ` Namhyung Kim
2013-10-15  7:44   ` Ingo Molnar
2013-10-15 13:45     ` David Ahern
2013-10-15 13:35   ` David Ahern
2013-10-16  1:52     ` Namhyung Kim
2013-10-16  1:58       ` David Ahern

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=20131015060200.GA3866@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@ghostprotocols.net \
    --cc=dsahern@gmail.com \
    --cc=efault@gmx.de \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.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 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.