From: Qu Wenruo <[email protected]>
To: Ammar Faizi <[email protected]>, Chris Mason <[email protected]>,
Josef Bacik <[email protected]>,
David Sterba <[email protected]>, Tejun Heo <[email protected]>
Cc: Lai Jiangshan <[email protected]>,
Filipe Manana <[email protected]>,
Linux Btrfs Mailing List <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
Linux Fsdevel Mailing List <[email protected]>,
GNU/Weeb Mailing List <[email protected]>
Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs
Date: Mon, 27 Feb 2023 18:18:43 +0800 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 2023/2/27 00:02, Ammar Faizi wrote:
> Hi,
>
> This is an RFC patchset that introduces the `wq_cpu_set` mount option.
> This option lets the user specify a CPU set that the Btrfs workqueues
> will use.
>
> Btrfs workqueues can slow sensitive user tasks down because they can use
> any online CPU to perform heavy workloads on an SMP system. Add a mount
> option to isolate the Btrfs workqueues to a set of CPUs. It is helpful
> to avoid sensitive user tasks being preempted by Btrfs heavy workqueues.
I'm not sure if pinning the wq is really the best way to your problem.
Yes, I understand you want to limit the CPU usage of btrfs workqueues,
but have you tried "thread_pool=" mount option?
That mount option should limit the max amount of in-flight work items,
thus at least limit the CPU usage.
For the wq CPU pinning part, I'm not sure if it's really needed,
although it's known CPU pinning can affect some performance characteristics.
Thanks,
Qu
>
> This option is similar to the taskset bitmask except that the comma
> separator is replaced with a dot. The reason for this is that the mount
> option parser uses commas to separate mount options.
>
> Figure (the CPU usage when `wq_cpu_set` is used VS when it is not):
> https://gist.githubusercontent.com/ammarfaizi2/a10f8073e58d1712c1ed49af83ae4ad1/raw/a4f7cbc4eb163db792a669d570ff542495e8c704/wq_cpu_set.png
>
> A simple stress testing:
>
> 1. Open htop.
> 2. Open a new terminal.
> 3. Mount and perform a heavy workload on the mounted Btrfs filesystem.
>
> ## Test without wq_cpu_set
> sudo mount -t btrfs -o rw,compress-force=zstd:15,commit=1500 /dev/sda2 hdd/a;
> cp -rf /path/folder_with_many_large_files/ hdd/a/test;
> sync; # See the CPU usage in htop.
> sudo umount hdd/a;
>
> ## Test wq_cpu_set
> sudo mount -t btrfs -o rw,compress-force=zstd:15,commit=1500,wq_cpu_set=0.4.1.5 /dev/sda2 hdd/a;
> cp -rf /path/folder_with_many_large_files/ hdd/a/test;
> sync; # See the CPU usage in htop.
> sudo umount hdd/a;
>
> Signed-off-by: Ammar Faizi <[email protected]>
> ---
>
> Ammar Faizi (6):
> workqueue: Add set_workqueue_cpumask() helper function
> btrfs: Change `mount_opt` type in `struct btrfs_fs_info` to `u64`
> btrfs: Create btrfs CPU set struct and helpers
> btrfs: Add wq_cpu_set=%s mount option
> btrfs: Adjust the default thread pool size when `wq_cpu_set` option is used
> btrfs: Add `BTRFS_DEFAULT_MAX_THREAD_POOL_SIZE` macro
>
> fs/btrfs/async-thread.c | 51 ++++++++++++++++++++
> fs/btrfs/async-thread.h | 3 ++
> fs/btrfs/disk-io.c | 6 ++-
> fs/btrfs/fs.c | 97 +++++++++++++++++++++++++++++++++++++++
> fs/btrfs/fs.h | 12 ++++-
> fs/btrfs/super.c | 83 +++++++++++++++++++++++++++++++++
> include/linux/workqueue.h | 3 ++
> kernel/workqueue.c | 19 ++++++++
> 8 files changed, 271 insertions(+), 3 deletions(-)
>
>
> base-commit: 2fcd07b7ccd5fd10b2120d298363e4e6c53ccf9c
next prev parent reply other threads:[~2023-02-27 10:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-26 16:02 [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 1/6] workqueue: Add set_workqueue_cpumask() helper function Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 2/6] btrfs: Change `mount_opt` type in `struct btrfs_fs_info` to `u64` Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 3/6] btrfs: Create btrfs CPU set struct and helpers Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 4/6] btrfs: Add wq_cpu_set=%s mount option Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 5/6] btrfs: Adjust the default thread pool size when `wq_cpu_set` option is used Ammar Faizi
2023-02-26 16:02 ` [RFC PATCH v1 6/6] btrfs: Add `BTRFS_DEFAULT_MAX_THREAD_POOL_SIZE` macro Ammar Faizi
2023-02-26 17:01 ` [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs Tejun Heo
2023-02-26 18:26 ` Ammar Faizi
2023-02-26 18:29 ` Ammar Faizi
2023-02-27 10:18 ` Qu Wenruo [this message]
2023-02-27 13:42 ` Ammar Faizi
2023-02-27 23:49 ` Qu Wenruo
2023-02-27 11:02 ` Filipe Manana
[not found] ` <[email protected]>
2023-02-27 13:45 ` Ammar Faizi
2023-02-27 16:24 ` Roman Mamedov
2023-02-27 22:17 ` Dave Chinner
2023-02-28 8:01 ` Ammar Faizi
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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