I'm pissed this was committed. It wasn't ready and in total breach of protocol.
This matter is *NOT* settled and you're lucky I don't just remove it from the tree.

In D18351#391315, @kib wrote:

And I still want my knob to not loose any trim :(.

Couple of minor nits, but otherwise looks OK.

My acceptance is provisional here.

In D18351#390605, @mckusick wrote:

This now looks reasonable to me.

At the moment during block shortages we request speedup of retiring TRIMs. But if there are no TRIMs (or we are on a disk that does not support TRIMs) then it seems to me that we should fall back to doing write speedup. Is this a change that we should make at the filesystem level, or should the drive recognize that if it is asked to speedup TRIMs and there are no TRIMs to speed up, then it should fall back to speeding up writes?

I like this, independent of a standalone utility.

a quick scan doesn't reveal anything major.

First pass at turning off write limiting when in speedup mode.

OK. I've updated this in a few ways:

Fixup after rebase oops

Update based on Kirk's comments and some thinking about the problem.

Ignore write speedup requests.

Fold Kirk's suggestions in, but only his diff, not the one to remove one of my calls.

Kirk sent me this (patch has been removed, but integrated into next update, but I've not yet internalized it enough to comment tonight):

In D18351#389989, @kib wrote:

I never saw a situation where SU workitems were the cause of the memory shortage. I understand that slow trims can cause filesystem write hiccups and that the change would somewhat lessen this.

Since, as noted above, the SU workitems shortage does not cause system instability, only performance problems, I would prefer that the abort of requested trims was controlled by an option, perhaps even per-mount. For instance, on my w/s I never have low memory condition but often do large metadata-intensive ops and I do not want to loose the useful hints which manage the SSDs lifespan.

Again with the changes, this time including all the changes.

Address review feedback.

updated with kasserts enabled as much as I can...

KASSERT where possible...

cem's changes

OK. I think that some of the other ways to spell stuff may be more obscure.

This was committed a long time ago...

I don't think we need email= anymore.

Seems reasonable to me.

In D17973#384258, @garga wrote:

Since I don't have a src bit, may I add "Approved by: imp"?

Looks good. I have a couple of suggested tweaks that make things better imho, but if you don't like one or the other, you can ignore.
I trust whatever you decide, so I'm clicking 'accept' to not hold things up.

FWIW, we run MAXPHYS of 8MB at Netflix. There's been talk of bumping MAXPHYS to 1MB from 128k since it helps a lot on more modern devices.

Looks good to me. I'd do a separate commit that just says 'CTM will move to ports in FreeBSD 13' in the ctm man page and get that merged before 12.0R (so ASAP).
I agree with Rob we should have an updating entry, and a line in the release notes (relnotes: yes should do that).
I don't think we need to do anything more other than commit this review after a few month (there's no rush, and safely after the turbulence 12.0R is mildly better), but I'll give that feedback and leave the timing to your discretion.

Please also add to MINIMAL

Seems to achieve the desired policy goals.

Seems legit to me. I like the abstraction even if we don't determine the size in multiple places.

This looks good to my eye. I'll rebase and commit after a quick test unless I hear otherwise....

I'm uneasy about doing this automatically... What if I already have a good compiler? Last thing I want is to rebuild clang a bazillion times while I'm iterating through kernel build issues on N platforms.

OK. Since there's not a simple place to point people, let's get this in.

these look good to me. Just a question over putting intel_ in a name for a facility that looks like it might be more generic than that...

This looks sane to me. At least the few places I spot-checked did. And it passes the 'not too terrible to look at' test too, which is nice.

I dislike the ls, but have no better suggestion,

Looks good to me...

In D17739#379433, @dteske wrote:

In D17739#379046, @jmg wrote:

oh, don't forget to bump date!

There's no date to bump?

We've fixed this via other means.
I have no plans to commit this. It's not needed. Kyle fixed all the issues.