From: Chris Murphy <lists@colorremedies.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: 5.6, slow send/receive, < 1MB/s
Date: Mon, 4 May 2020 02:25:31 -0600 [thread overview]
Message-ID: <CAJCQCtT6rnH75f8wC8uf+-NnxEsZtmoRhM9cE37QTR0TF6xqJQ@mail.gmail.com> (raw)
In-Reply-To: <2ae5353b-461b-6a87-227c-f13b0c2ccfe2@suse.com>
On Mon, May 4, 2020 at 2:13 AM Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> On 4.05.20 г. 11:03 ч., Chris Murphy wrote:
> > receive (rw,noatime,seclabel,compress-force=zstd:5,space_cache=v2,subvolid=5,subvol=/)
> > send (rw,noatime,seclabel,compress=zstd:1,nossd,notreelog,space_cache=v2,subvolid=5,subvol=/)
> >
> > Both are on dm-crypt.
> >
> > perf top -g -U consumes about 85% CPU according to top, and every time
> > I run it, the btrfs send performance *increases*. When I cancel this
> > perf top command, it returns to the slower performance. Curious.
> >
>
> Well this still doesn't show the stack traces, after all the + sign
> means you can expand that (with the 'e' key). But looking at this I
> don't see any particular lock contention - just compression-related
> functions.
I'm not sure which ones...
Samples
Children Self Shared Object Symbol
- 62.58% 0.10% [kernel] [k]
entry_SYSCALL_64_after_hwframe
◆
- 62.47% entry_SYSCALL_64_after_hwframe
▒
- 62.17% do_syscall_64
▒
- 23.84% ksys_read
▒
- 23.62% vfs_read
▒
- 14.79% proc_reg_read
▒
- seq_read
▒
- 7.07% s_show
▒
- seq_printf
▒
- vsnprintf
▒
1.87% format_decode
▒
1.49% number
▒
0.84% string
▒
0.68% memcpy_erms
▒
- 6.23% s_next
▒
- update_iter
▒
4.49% module_get_kallsym
▒
1.41% kallsyms_expand_symbol.constprop.0
▒
- 0.79% s_start
▒
- update_iter
▒
0.57% module_get_kallsym
▒
- 8.38% new_sync_read
▒
- 8.35% pipe_read
▒
- 6.46% __mutex_lock.constprop.0
▒
6.33% mutex_spin_on_owner
▒
- 0.86% copy_page_to_iter
▒
- 0.78% copyout
▒
0.77% copy_user_enhanced_fast_string
▒
- 17.96% __x64_sys_splice
▒
- 17.92% do_splice
▒
7.80% mutex_unlock
▒
- 4.55% pipe_double_lock
▒
- 2.88% mutex_lock
▒
0.95% _cond_resched
▒
- 2.61% mutex_lock
▒
0.82% _cond_resched
▒
0.52% pipe_unlock
▒
- 9.80% __x64_sys_ioctl
▒
- ksys_ioctl
▒
- 9.79% rpc_populate.constprop.0
▒
For a higher level overview, try: perf top --sort comm,dso
▒
--
Chris Murphy
next prev parent reply other threads:[~2020-05-04 8:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 7:43 5.6, slow send/receive, < 1MB/s Chris Murphy
2020-05-04 7:47 ` Nikolay Borisov
2020-05-04 8:03 ` Chris Murphy
2020-05-04 8:12 ` Chris Murphy
2020-05-04 8:13 ` Nikolay Borisov
2020-05-04 8:25 ` Chris Murphy [this message]
2020-05-04 8:43 ` Chris Murphy
2020-05-06 5:48 ` Chris Murphy
2020-05-06 21:04 ` Chris Murphy
2020-05-06 21:07 ` Chris Murphy
2020-05-23 16:11 ` Jorge Bastos
2020-05-23 16:42 ` A L
2020-06-06 16:16 ` Jorge Bastos
2020-06-06 16:24 ` Jorge Bastos
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=CAJCQCtT6rnH75f8wC8uf+-NnxEsZtmoRhM9cE37QTR0TF6xqJQ@mail.gmail.com \
--to=lists@colorremedies.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).