On Mon, Apr 29, 2024 at 07:30:41PM +0100, Al Viro wrote:
> 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.
Ugh... Forgot to push it out, sorry. Branch pushed out now,
individual patches in followups.
Summary of changes compared to posted variant:
__bd_flags is atomic_t now.
atomic_{or,andnot} is used instead of cmpxchg().
the constants (BD_READ_ONLY, etc.) are masks, not flag numbers.
