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 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.