From: Christoph Hellwig <hch@lst.de>
To: Chris Mason <clm@meta.com>
Cc: Christoph Hellwig <hch@lst.de>,
Qu Wenruo <quwenruo.btrfs@gmx.com>, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Johannes Thumshirn <jth@kernel.org>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 03/10] btrfs: offload all write I/O completions to a workqueue
Date: Sat, 25 Mar 2023 09:15:15 +0100 [thread overview]
Message-ID: <20230325081515.GC7353@lst.de> (raw)
In-Reply-To: <14e253bb-8530-af11-7395-9e4148249c54@meta.com>
On Fri, Mar 24, 2023 at 09:25:07AM -0400, Chris Mason wrote:
> As you mentioned above, we're currently doing synchronous crcs for
> metadata when BTRFS_FS_CSUM_IMPL_FAST, and for synchronous writes.
> We've benchmarked this a few times and I think with modern hardware a
> better default is just always doing synchronous crcs for data too.
>
> Qu or David have you looked synchronous data crcs recently?
As mentioend in the other mail I have a bit. But only for crc32
so far, and only on x86, so the matrix might be a little more
complicated.
> My preference would be:
>
> - crcs are always inline if your hardware is fast
> - Compression, encryption, slow hardware crcs use the thread_pool_size knob
> - We don't try to limit the other workers
>
> The idea behind the knob is just "how much of your CPU should each btrfs
> mount consume?" Obviously we'll silently judge anyone that chooses less
> than 100% but I guess it's good to give people options.
Ok. I'll do a series about the nobs ASAP, and then the inline CRCs
next.
next prev parent reply other threads:[~2023-03-25 8:17 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 16:59 defer all write I/O completions to process context Christoph Hellwig
2023-03-14 16:59 ` [PATCH 01/10] btrfs: use a plain workqueue for ordered_extent processing Christoph Hellwig
2023-03-16 17:10 ` Johannes Thumshirn
2023-03-16 17:31 ` David Sterba
2023-03-20 6:12 ` Christoph Hellwig
2023-03-20 11:08 ` Qu Wenruo
2023-03-20 11:35 ` Qu Wenruo
2023-03-20 12:24 ` Christoph Hellwig
2023-03-20 23:19 ` Qu Wenruo
2023-03-21 12:48 ` Christoph Hellwig
2023-03-14 16:59 ` [PATCH 02/10] btrfs: refactor btrfs_end_io_wq Christoph Hellwig
2023-03-16 17:12 ` Johannes Thumshirn
2023-03-20 11:09 ` Qu Wenruo
2023-03-14 16:59 ` [PATCH 03/10] btrfs: offload all write I/O completions to a workqueue Christoph Hellwig
2023-03-16 17:14 ` Johannes Thumshirn
2023-03-20 11:29 ` Qu Wenruo
2023-03-20 12:30 ` Christoph Hellwig
2023-03-20 23:37 ` Qu Wenruo
2023-03-21 12:55 ` Christoph Hellwig
2023-03-21 23:37 ` Qu Wenruo
2023-03-22 8:32 ` Christoph Hellwig
2023-03-23 8:07 ` Qu Wenruo
2023-03-23 8:12 ` Christoph Hellwig
2023-03-23 8:20 ` Qu Wenruo
2023-03-24 1:11 ` Christoph Hellwig
2023-03-23 14:53 ` Chris Mason
2023-03-24 1:09 ` Christoph Hellwig
2023-03-24 13:25 ` Chris Mason
2023-03-24 19:20 ` Chris Mason
2023-03-25 8:13 ` Christoph Hellwig
2023-03-25 17:16 ` Chris Mason
2023-03-25 8:15 ` Christoph Hellwig [this message]
2023-03-25 8:42 ` Qu Wenruo
2023-03-14 16:59 ` [PATCH 04/10] btrfs: remove the compressed_write_workers workqueue Christoph Hellwig
2023-03-14 16:59 ` [PATCH 05/10] btrfs: remove irq disabling for btrfs_workqueue.list_lock Christoph Hellwig
2023-03-17 10:34 ` Johannes Thumshirn
2023-03-14 16:59 ` [PATCH 06/10] btrfs: remove irq disabling for subpage.list_lock Christoph Hellwig
2023-03-14 16:59 ` [PATCH 07/10] btrfs: remove irq disabling for leak_lock Christoph Hellwig
2023-03-17 10:35 ` Johannes Thumshirn
2023-03-14 16:59 ` [PATCH 08/10] btrfs: remove irq disabling for fs_info.ebleak_lock Christoph Hellwig
2023-03-17 10:35 ` Johannes Thumshirn
2023-03-14 16:59 ` [PATCH 09/10] btrfs: remove irq_disabling for ordered_tree.lock Christoph Hellwig
2023-03-17 10:36 ` Johannes Thumshirn
2023-03-20 6:12 ` Christoph Hellwig
2023-03-14 16:59 ` [PATCH 10/10] btrfs: remove confusing comments Christoph Hellwig
2023-03-17 10:37 ` Johannes Thumshirn
2023-03-17 10:39 ` defer all write I/O completions to process context Johannes Thumshirn
2023-03-20 6:14 ` Christoph Hellwig
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=20230325081515.GC7353@lst.de \
--to=hch@lst.de \
--cc=clm@fb.com \
--cc=clm@meta.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=jth@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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