GNU/Weeb Mailing List <[email protected]>
 help / color / mirror / Atom feed
From: Dave Chinner <[email protected]>
To: Ammar Faizi <[email protected]>
Cc: Chris Mason <[email protected]>, Josef Bacik <[email protected]>,
	David Sterba <[email protected]>, Tejun Heo <[email protected]>,
	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: Tue, 28 Feb 2023 09:17:45 +1100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Sun, Feb 26, 2023 at 11:02:53PM +0700, Ammar Faizi wrote:
> ## 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;

This seems like the wrong model for setting cpu locality for
internal filesystem threads.

Users are used to controlling cpu sets and other locality behaviour
of a task with wrapper tools like numactl. Wrap th emount command
with a numactl command to limit the CPU set, then have the btrfs
fill_super() callback set the cpu mask for the work queues it
creates based on the cpu mask that has been set for the mount task.

That is, I think the model should be "inherit cpu mask from parent
task" rather than adding mount options. This model allows anything
that numactl can control (e.g. memory locality) to also influence
the filesystem default behaviour without having to add yet more
mount options in the future....

-Dave.
-- 
Dave Chinner
[email protected]

  parent reply	other threads:[~2023-02-27 22:17 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
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 [this message]
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