All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@lst.de>
Cc: 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 01/10] btrfs: use a plain workqueue for ordered_extent processing
Date: Tue, 21 Mar 2023 07:19:30 +0800	[thread overview]
Message-ID: <675712c0-ac72-f923-247c-31f0b22a8657@gmx.com> (raw)
In-Reply-To: <20230320122420.GA9008@lst.de>



On 2023/3/20 20:24, Christoph Hellwig wrote:
> On Mon, Mar 20, 2023 at 07:35:45PM +0800, Qu Wenruo wrote:
>> In fact, I believe we not only need to add workqueue_set_max_active() for
>> the thread_pool= mount option, but also add a test case for thread_pool=1
>> to shake out all the possible hidden bugs...
>>
>> Mind me to send a patch adding the max_active setting for all plain
>> workqueues?
> 
> I don't think blindly doing that is a good idea.  As explained in my
> reply to Dave, going all the way back to 2014, all workqueues hat had
> a less than default treshold never used it to start with.
> 
> I'm also really curious (and I might have to do some digging) what
> the intended use case is, and if it actually works as-is.  I know
> one of your workloads mentioned a higher concurrency for some HDD
> workloads, do you still remember what the workloads are?

In fact, recently we had a patchset trying to adding a new mount option 
to pin workqueue loads to certain CPUs.

The idea of that patchset is to limit the CPU usage for compression/csum 
generation.

This can also apply to scrub workload.


The other thing is, I also want to test if we could really have certain 
deadlock related to workqueue.
Currently thread_pool= mount option only changes the btrfs workqueues, 
not the new plain ones.

Thanks,
Qu
>  Because
> I'm pretty sure it won't be needed for all workqueues, and the fact
> that btrfs is the only caller of workqueue_set_max_active in the
> entire kernel makes me very sceptical that we do need it everywhere.
> 
> So I'd be much happier to figure out where we needed it first, but even
> if not and we want to restore historic behavior from some point in the
> past we'd still only need to apply it selectively.

  reply	other threads:[~2023-03-20 23:20 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 [this message]
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
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=675712c0-ac72-f923-247c-31f0b22a8657@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=jth@kernel.org \
    --cc=linux-btrfs@vger.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.