All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Christoph Hellwig <hch@lst.de>,
	xni@redhat.com, colyli@kernel.org, axboe@kernel.dk,
	agk@redhat.com, snitzer@kernel.org, mpatocka@redhat.com,
	song@kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, dm-devel@lists.linux.dev,
	linux-raid@vger.kernel.org, yi.zhang@huawei.com,
	yangerkun@huawei.com, kbusch@kernel.org,
	"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH RFC v2 00/14] md: introduce a new lockless bitmap
Date: Wed, 9 Apr 2025 11:40:19 +0200	[thread overview]
Message-ID: <20250409094019.GA3890@lst.de> (raw)
In-Reply-To: <115c3b08-aff1-dd97-fe6a-7901452ce62c@huaweicloud.com>

On Wed, Apr 09, 2025 at 05:27:11PM +0800, Yu Kuai wrote:
>> For that you'd be much better of just creating your own trivial
>> file_system_type with an inode fully controlled by your driver
>> that has a trivial set of address_space ops instead of oddly
>> mixing with the block layer.
>
> Yes, this is exactly what I said implement a new file_operations(and
> address_space ops), I wanted do this the easy way, just reuse the raw
> block device ops, this way I just need to implement the submit_bio ops
> for new hidden disk.
>
> I can try with new fs type if we really think this solution is too
> hacky, however, the code line will be much more. :(

I don't think it should be much more.  It'll also remove the rather
unexpected indirection through submit_bio.  Just make sure you use
iomap for your operations, and implement the submit_io hook.  That
will also be more efficient than the buffer_head based block ops
for writes.

>>
>> Note that either way I'm not sure using the page cache here is an
>> all that good idea, as we're at the bottom of the I/O stack and
>> thus memory allocations can very easily deadlock.
>
> Yes, for the page from bitmap, this set do the easy way just read and
> ping all realted pages while loading the bitmap. For two reasons:
>
> 1) We don't need to allocate and read pages from IO path;(In the first
> RFC version, I'm using a worker to do that).

You still depend on the worker, which will still deadlock.

>> What speaks against using your own folios explicitly allocated at
>> probe time and then just doing manual submit_bio on that?  That's
>> probably not much more code but a lot more robust.
>
> I'm not quite sure if I understand you correctly. Do you means don't use
> pagecache for bitmap IO, and manually create BIOs like the old bitmap,
> meanwhile invent a new solution for synchronism instead of the global
> spin_lock from old bitmap?

Yes.  Alternatively you need to pre-populate the page cache and keep
extra page references.


  reply	other threads:[~2025-04-09  9:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-28  6:08 [PATCH RFC v2 00/14] md: introduce a new lockless bitmap Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 01/14] block: factor out a helper bdev_file_alloc() Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 02/14] md/md-bitmap: pass discard information to bitmap_{start, end}write Yu Kuai
2025-04-04  9:29   ` Christoph Hellwig
2025-04-07  1:19     ` Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 03/14] md/md-bitmap: remove parameter slot from bitmap_create() Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 04/14] md: add a new sysfs api bitmap_version Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 05/14] md: delay registeration of bitmap_ops until creating bitmap Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 06/14] md/md-llbitmap: implement bit state machine Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 07/14] md/md-llbitmap: implement hidden disk to manage bitmap IO Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 08/14] md/md-llbitmap: implement APIs for page level dirty bits synchronization Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 09/14] md/md-llbitmap: implement APIs to mange bitmap lifetime Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 10/14] md/md-llbitmap: implement APIs to dirty bits and clear bits Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 11/14] md/md-llbitmap: implement APIs for sync_thread Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 12/14] md/md-llbitmap: implement all bitmap operations Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 13/14] md/md-llbitmap: implement sysfs APIs Yu Kuai
2025-03-28  6:08 ` [PATCH RFC v2 14/14] md/md-llbitmap: add Kconfig Yu Kuai
2025-03-28 11:06 ` [PATCH RFC v2 00/14] md: introduce a new lockless bitmap Christoph Hellwig
2025-03-29  1:11   ` Yu Kuai
2025-04-09  8:32     ` Christoph Hellwig
2025-04-09  9:27       ` Yu Kuai
2025-04-09  9:40         ` Christoph Hellwig [this message]
2025-04-11  1:36           ` Yu Kuai
2025-04-19  8:46             ` Yu Kuai
2025-04-21  7:39               ` Christoph Hellwig
2025-04-04  9:27 ` Christoph Hellwig
2025-04-07  1:09   ` Yu Kuai

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=20250409094019.GA3890@lst.de \
    --to=hch@lst.de \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=colyli@kernel.org \
    --cc=dm-devel@lists.linux.dev \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.org \
    --cc=song@kernel.org \
    --cc=xni@redhat.com \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.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.