All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH RFC 0/3] btrfs: Performance profiler support
Date: Thu, 7 Mar 2019 17:12:05 +0100	[thread overview]
Message-ID: <20190307161203.GJ31119@twin.jikos.cz> (raw)
In-Reply-To: <ccf67c41-752a-6812-0de7-34f39c37ecac@gmx.com>

On Thu, Mar 07, 2019 at 10:18:49PM +0800, Qu Wenruo wrote:
> > Well, most of that is answered by 'figure out how to use tracepoints and
> > perf for that'.
> > 
> > If there were not a whole substystem, actively maintained and
> > documented, implementing something like that might help, but that's not
> > the case.
> > 
> > I see what you were able to understand from the results, but it's more
> > like a custom analysis tool that should not merged as-is. It brings a
> > whole new interface and that's always hard to get right with all the
> > mistakes ahead that somebody has probably solved already.
> > 
> > It would be good to have list of the limitations of perf you see, and we
> > can find a solution ourselves or ask elsewhere.
> 
> Add linux-perf-users mail list.
> 
> I should mention the problem of ftrace (or my perf skill) in cover letter.
> 
> The biggest problem is the conflicts between detailed function execution
> duration and classification.
> 
> For tree lock case, indeed we can use function graph to get execution
> duration of btrfs_tree_read_lock() and btrfs_tree_lock().
> But that's all. We can't really do much classification.
> 
> If just use trace event, with trace event added, then we can't get the
> execution duration.

I think you can save the start and end times and put the delta to the
tracepoint output.

  reply	other threads:[~2019-03-07 16:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06  6:19 [PATCH RFC 0/3] btrfs: Performance profiler support Qu Wenruo
2019-03-06  6:19 ` [PATCH RFC 1/3] btrfs: Introduce performance profiler Qu Wenruo
2019-03-06  6:19 ` [PATCH RFC 2/3] btrfs: locking: Add hooks for btrfs perf Qu Wenruo
2019-03-06  6:19 ` [PATCH RFC 3/3] btrfs: perf: Add RO sysfs interface to collect perf result Qu Wenruo
2019-03-07 14:02 ` [PATCH RFC 0/3] btrfs: Performance profiler support David Sterba
2019-03-07 14:18   ` Qu Wenruo
2019-03-07 16:12     ` David Sterba [this message]
2019-03-09  6:21       ` Nikolay Borisov
2019-03-09  6:32         ` Qu Wenruo
2019-03-10  3:08 ` Anand Jain
2019-03-10  9:29   ` Nikolay Borisov
2019-03-10  9:34     ` Qu Wenruo
2019-03-10  9:40       ` Nikolay Borisov
2019-03-10  9:56         ` Qu Wenruo
2019-03-10 10:00           ` Nikolay Borisov
2019-03-11  0:44     ` Anand Jain

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=20190307161203.GJ31119@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.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 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.