All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>, Tejun Heo <tj@kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Filipe Manana <fdmanana@suse.com>,
	Linux Btrfs Mailing List <linux-btrfs@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Fsdevel Mailing List <linux-fsdevel@vger.kernel.org>,
	GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>
Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs
Date: Tue, 28 Feb 2023 15:01:06 +0700	[thread overview]
Message-ID: <Y/20wsdwxx8OSw/+@biznet-home.integral.gnuweeb.org> (raw)
In-Reply-To: <20230227221745.GI2825702@dread.disaster.area>

On Tue, Feb 28, 2023 at 09:17:45AM +1100, Dave Chinner wrote:
> 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....

Good idea on the tooling part.

I like the idea of using numactl to determine a proper CPU set. But
users may also use /etc/fstab to mount their btrfs storage. In that
case, using mount option is still handy.

Also, if we always inherit CPU mask from the parent task who calls the
mount, it will be breaking the CPU affinity for old users who
inadvertently call their mount cmd with random CPU mask.

We should keep the old behavior and allow user to opt in if they want
to. Maybe something like:

   numactl -N 0 mount -t btrfs -o rw,wq_cpu_set=inherit /dev/bla bla

-- 
Ammar Faizi


      reply	other threads:[~2023-02-28  8:02 UTC|newest]

Thread overview: 20+ 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
     [not found] ` <20230227030438.3655-1-hdanton@sina.com>
2023-02-27  9:48   ` 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
2023-02-27 11:46   ` Qu Wenruo
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 [this message]

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=Y/20wsdwxx8OSw/+@biznet-home.integral.gnuweeb.org \
    --to=ammarfaizi2@gnuweeb.org \
    --cc=clm@fb.com \
    --cc=david@fromorbit.com \
    --cc=dsterba@suse.com \
    --cc=fdmanana@suse.com \
    --cc=gwml@vger.gnuweeb.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /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.