From: Al Viro <viro@zeniv.linux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-fsdevel@vger.kernel.org, Yu Kuai <yukuai1@huaweicloud.com>,
linux-block@vger.kernel.org,
Christian Brauner <brauner@kernel.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCHES][RFC] packing struct block_device flags
Date: Mon, 29 Apr 2024 19:30:41 +0100 [thread overview]
Message-ID: <20240429183041.GC2118490@ZenIV> (raw)
In-Reply-To: <20240429181300.GB2118490@ZenIV>
On Mon, Apr 29, 2024 at 07:13:00PM +0100, Al Viro wrote:
> On Mon, Apr 29, 2024 at 06:02:09PM +0100, Al Viro wrote:
> > On Mon, Apr 29, 2024 at 08:31:07AM +0100, Al Viro wrote:
> >
> > > FWIW, we could go for atomic_t there and use
> > > atomic_read() & 0xff
> > > for partno, with atomic_or()/atomic_and() for set/clear and
> > > atomic_read() & constant for test. That might slightly optimize
> > > set/clear on some architectures, but setting/clearing flags is
> > > nowhere near hot enough for that to make a difference.
> >
> > Incremental for that (would be folded into 3/8 if we went that way)
> > is below; again, I'm not at all sure it's idiomatic enough to bother
> > with, but that should at least show what's going on:
>
> Or this, for that matter:
See #work.bd_flags-2 for carve-up of that variant.
next prev parent reply other threads:[~2024-04-29 18:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-28 5:12 [PATCHES][RFC] packing struct block_device flags Al Viro
2024-04-28 5:14 ` [PATCH 1/8] Use bdev_is_paritition() instead of open-coding it Al Viro
2024-04-29 5:19 ` Christoph Hellwig
2024-04-28 5:15 ` [PATCH 2/8] wrapper for access to ->bd_partno Al Viro
2024-04-28 5:16 ` [PATCH 3/8] bdev: infrastructure for flags Al Viro
2024-04-28 5:17 ` [PATCH 4/8] bdev: move ->bd_read_only to ->__bd_flags Al Viro
2024-04-28 5:18 ` [PATCH 5/8] bdev: move ->bd_write_holder into ->__bd_flags Al Viro
2024-04-28 5:19 ` [PATCH 6/8] bdev: move ->bd_has_subit_bio to ->__bd_flags Al Viro
2024-04-28 5:19 ` [PATCH 7/8] bdev: move ->bd_ro_warned " Al Viro
2024-04-28 5:21 ` [PATCH 8/8] bdev: move ->bd_make_it_fail " Al Viro
2024-04-29 5:23 ` [PATCHES][RFC] packing struct block_device flags Christoph Hellwig
2024-04-29 7:31 ` Al Viro
2024-04-29 17:02 ` Al Viro
2024-04-29 18:13 ` Al Viro
2024-04-29 18:30 ` Al Viro [this message]
2024-05-03 0:06 ` Al Viro
2024-05-03 0:07 ` [PATCH 1/8] Use bdev_is_paritition() instead of open-coding it Al Viro
2024-05-03 0:07 ` [PATCH 2/8] wrapper for access to ->bd_partno Al Viro
2024-05-03 0:08 ` [PATCH v2 3/8] bdev: infrastructure for flags Al Viro
2024-05-03 0:09 ` [PATCH v2 4/8] bdev: move ->bd_read_only to ->__bd_flags Al Viro
2024-05-03 0:09 ` [PATCH v2 5/8] bdev: move ->bd_write_holder into ->__bd_flags Al Viro
2024-05-03 0:10 ` [PATCH v2 6/8] bdev: move ->bd_has_subit_bio to ->__bd_flags Al Viro
2024-05-03 0:10 ` [PATCH v2 7/8] bdev: move ->bd_ro_warned " Al Viro
2024-05-03 0:11 ` [PATCH v2 8/8] bdev: move ->bd_make_it_fail " Al Viro
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=20240429183041.GC2118490@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=yukuai1@huaweicloud.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.