From: Christoph Hellwig <hch@lst.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Christoph Hellwig <hch@lst.de>, 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: Fri, 24 Mar 2023 02:11:38 +0100 [thread overview]
Message-ID: <20230324011138.GC12152@lst.de> (raw)
In-Reply-To: <6b1d2d63-ef00-3c6c-8bea-481e46b6fcef@gmx.com>
On Thu, Mar 23, 2023 at 04:20:45PM +0800, Qu Wenruo wrote:
> I'm just wondering if we all know that we should avoid cross-workqueue
> dependency to avoid deadlock, then why no one is trying to expose any such
> deadlocks by simply limiting max_active to 1 for all workqueues?
Cross workqueue dependencies are not a problem per se, and a lot of
places in the kernel rely on them. Dependencies on another work_struct
on the same workqueue on the other hand are a problem.
> Especially with lockdep, once we got a reproduce, it should not be that
> hard to fix.
lockdep helps you to find them without requiring to limit the max_active.
next prev parent reply other threads:[~2023-03-24 1:11 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 [this message]
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=20230324011138.GC12152@lst.de \
--to=hch@lst.de \
--cc=clm@fb.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