All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH 5/5] perf tools: Fix data_read_offset() file opening
Date: Tue, 19 May 2015 21:55:49 -0300	[thread overview]
Message-ID: <20150520005549.GH26111@kernel.org> (raw)
In-Reply-To: <20150520004437.GF22713@sejong>

Em Wed, May 20, 2015 at 09:44:37AM +0900, Namhyung Kim escreveu:
> On Tue, May 19, 2015 at 10:58:43PM +0300, Adrian Hunter wrote:
> > On 19/05/2015 5:48 p.m., Namhyung Kim wrote:
> > >Hi Adrian,
> > >
> > >On Tue, May 19, 2015 at 04:05:46PM +0300, Adrian Hunter wrote:
> > >>Patch "perf tools: Protect dso cache fd with a mutex"
> > >>changed data_file_size() to open the data file if it
> > >>was not open.
> > >>
> > >>data_read_offset() was calling data_file_size() to read
> > >>the data file size, but data_file_size() can fail to
> > >>open the file because the binary_type has not been set up.
> > >>
> > >>The correct function to call is dso__data_size() which
> > >>uses dso__data_fd() to open the file correctly.
> > >
> > >Right, but I worried about the locking overhead.  By using
> > >dso__data_size() it'll call dso__data_fd() everytime which grabs the
> > >dso__data_open_lock that is a global mutex.  It can be a performance
> > >bottleneck on multi-thread report IMHO.
> > >
> > >I assumed that correct code should check the data fd or size before
> > >calling read function as I read the comment in dso.h file.
> > >
> > >What about adding the missing check in a proper place instead?
> > 
> > It looks to me like you need to change data_file_size() and
> > dso_cache__read() so that they open the fd properly i.e. call
> > dso__data_fd() instead of open_dso().
> 
> OK, I'll change it to have a proper binary type before calling
> open_dso() like dso__data_fd() does.  But I still think it's good to
> open data fd explicitly before reading from dso cache.
> 
> 
> > 
> > dso__data_fd() should not be taking a lock because the lock must
> > be held while the fd in being used.
> > 
> > Perhaps there should be dso__get_fd() and dso__put_fd() that lock/open
> > and the unlock.
> 
> That is already a part of my patchset but not merged yet.

Ok, I have Adrian's patch in my perf/core branch, tomorrow I'll check
what you guys ended up agreeing on so that I can do the adjustments
before pushing to Ingo, ok?
 
> > But I will have to leave this to you because I am snowed with
> > my own problems.
> 
> No problem.  I can see you're doing hardwork ;-)

:-)

- Arnaldo

  reply	other threads:[~2015-05-20  0:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 13:05 [PATCH 0/5] perf tools: Some fixes Adrian Hunter
2015-05-19 13:05 ` [PATCH 1/5] perf tools: Fix function declarations needed by parse-events.y Adrian Hunter
2015-05-27 16:45   ` [tip:perf/core] " tip-bot for Adrian Hunter
2015-05-19 13:05 ` [PATCH 2/5] perf build: Fix libunwind feature detection on 32-bit x86 Adrian Hunter
2015-05-27 16:46   ` [tip:perf/core] " tip-bot for Adrian Hunter
2015-05-19 13:05 ` [PATCH 3/5] perf tools: Fix parse_events_error dereferences Adrian Hunter
2015-05-27 16:46   ` [tip:perf/core] " tip-bot for Adrian Hunter
2015-05-19 13:05 ` [PATCH 4/5] perf session: Fix perf_session__peek_event() Adrian Hunter
2015-05-27 16:46   ` [tip:perf/core] " tip-bot for Adrian Hunter
2015-05-19 13:05 ` [PATCH 5/5] perf tools: Fix data_read_offset() file opening Adrian Hunter
2015-05-19 14:48   ` Namhyung Kim
2015-05-19 19:58     ` Adrian Hunter
2015-05-20  0:44       ` Namhyung Kim
2015-05-20  0:55         ` Arnaldo Carvalho de Melo [this message]
2015-05-19 14:00 ` [PATCH 0/5] perf tools: Some fixes 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=20150520005549.GH26111@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@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.