Message-ID: <bqlnihgtaxv4gq2k6nah33hq7f3vk73x2sd6mlbdvxln2nbfu6@ypoukdqdqbtb>
Date: Wed, 13 Mar 2024 17:34:28 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Darrick J. Wong" <djwong@...nel.org>, linux-bcachefs@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs updates for 6.9

On Wed, Mar 13, 2024 at 01:47:59PM -0700, Linus Torvalds wrote:
> On Tue, 12 Mar 2024 at 18:10, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> > Hi Linus, few patches for you - plus a simple merge conflict with VFS
> > changes:
> 
> The conflicts are trivial.
> 
> The "make random bcachefs code be a library function" stuff I looked
> at, decided is senseless, and ended up meaning that I'm not pulling
> this without a lot more explanation (and honestly, I don't think the
> explanations would hold water).
> 
> That "stdio_redirect_printf()" and darray_char stuff is just
> horrendous interfaces with no explanations. The interfaces are
> disgusting.

It's a bidirectional pipe between a kthread and an fd. Not sure what's
complicated about that?

> And if you *do* make it a library thing, it needs to be
> 
>  (a) much more explained
> 
>  (b) have much saner naming, and fewer disgusting and completely
> nonsensical interfaces ("DARRAY()").

DARRAY() is just a dynamic array, aka a c++ vector; we open code those so
much it's _stupid_. I wouldn't be opposed to changing the name to
something more standard (Rust calls it a vector too); I started out with
the CCAN version and rewrote it later for hte kernel.

> And no, finding one other filesystem to share this kind of code is not
> sufficient to try to claim it's a sane interface and sane naming.
> 
> But the main dealbreaker is the insane math.
> 
> And dammit, we talked about the idiotic "mean and variance" garbage
> long ago. It was wrong back then, it's *still* wrong.
> 
> You didn't explain why it couldn't use the *much* simpler MAD (median
> absolute deviation) instead of using variance.

I most certainly did.

I liked your MAD suggestion, but the catch was that we need an
exponentially weighted version, not just the standard version, and I
haven't seen an derivation of exponentially weighted MAD and doing that
is a bit above my statistical pay grade. I explained all this at the
time.

Besides that, the existing code works fine, the u128 stuff is right out
of Knuth (divide is the only even vaguely tricky one), and it's nicely
self contained. It's fine.

> I called it insanely over-engineered back then, and as far as I can
> tell, absolutely *NOTHING* has changed apart from some slight type
> name details.
> 
> As long as you made it some kind of bcachefs-only thing, I don't mind.
> 
> But now you're trying to push this garbage as some kind of generic
> library code that others would use, and that immediately means that I
> *do* mind insanely overengineered interfaces.
> 
> The time_stats stuff otherwise looks at leask like a sane interface
> with names and uses, but the use of that horrendous infrastructure
> scuttles it.

Well, that leaves us at a bit of an impasse then because Darrick wants
this stuff for XFS (he was discovering useful stuff with it pretty much
right away) and I'm just not doing a MAD conversion, sorry. I'm just
being practical here, I like MAD in principle but that's too far outside
my wheelhouse.

Maybe we can get someone else interested? I have a feeling Peter could
whip it out in about 5 minutes...

Powered by blists - more mailing lists