All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <wqu@suse.de>, Anand Jain <anand.jain@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC 0/3] btrfs: Performance profiler support
Date: Sun, 10 Mar 2019 11:40:07 +0200	[thread overview]
Message-ID: <913b2ba4-5a3c-974e-10d0-26d65d4175ee@suse.com> (raw)
In-Reply-To: <bcd2e6de-cf5d-311d-ebdf-63eb1ae40222@suse.de>



On 10.03.19 г. 11:34 ч., Qu Wenruo wrote:
> 
> 
> On 2019/3/10 下午5:29, Nikolay Borisov wrote:
>>
>>
>> On 10.03.19 г. 5:08 ч., Anand Jain wrote:
>>>
>>>  I agree we need btrfs specific performance measurements and its
>>>  my list too.
>>>
>>>  However my idea was to add it as a btrfs-progs subcommand such as
>>>
>>>    btrfs inspect perf ...
>>>
>>>  And implement by using the systemtap/perf/bpf/dtrace, as these
>>>  can tap the kernel functions from the useland using which we
>>>  can measure the time taken and no kernel changes will be required.
>>>  But yes we need to update the btrfs-progs if we rename the kernel
>>>  function, which I think is ok.
>>>
>>>  I was too early trying this with bpf before, probably there are
>>>  more tools now to do that same thing.
>>
>> This is way too developer oriented to be included in the generic btrfs
>> tools. Frankly bpf makes sense but only as a separate script being
>> developed and possibly shared on github or whatnot so that other
>> interested people can use it. However, integrating with btrfs-progs
>> definitely seems the wrong thing to do.
>>
>> On the same note - I'm highly against this patchset landing in the kernel.
> 
> Are you against the interface part or the btrfs specific perf part?
> 
> For the first half, indeed the new sysfs is not good and I'm OK to move
> to any more established interface.
> 
> For the later half, if bfp/ftrace can do the same work, then I'm fine.
> Otherwise the need is still here, both developer or experienced sys
> admin will need this feature.

I'm against this functionality being part of btrfs. What would be more
useful is a set of bpf scripts which might very well be developed
alongside the main project. They will be a lot more flexible also they
will add overhead only when you really need them, whereas the current
approach AFAIK (I might be wrong, correct me if so) always accumulates
certain stats irrespective of whether the sys admin needs them or not?
At the very least you will sprinkle code such as :

'if (perf measurement enabled) ..... '

I'd really we didn't add this clutter.

> 
> Thanks,
> Qu
> 
> 

  reply	other threads:[~2019-03-10  9:40 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
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 [this message]
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=913b2ba4-5a3c-974e-10d0-26d65d4175ee@suse.com \
    --to=nborisov@suse.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.de \
    /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.