Change blist_alloc()'s allocation policy from first-fit to next-fit

[alc]

Summary

Change blist_alloc()'s allocation policy from first-fit to next-fit so that disk writes are more likely to be sequential. This change is beneficial on both the solid state and mechanical drives that I've tested. (A similar change in allocation policy was made by Dragonfly BSD not so long ago.)

Increase the width of blst_meta_alloc()'s parameter "skip" and the local variables whose values are derived from it to 64 bits. (This matches the width of the field "skip" that is stored in the structure "blist" and passed to blst_meta_alloc().)

Eliminate a pointless check for a NULL blist_t.

Simplify blst_meta_alloc()'s handling of the ALL-FREE case.

Address nearby style errors.

Test Plan

I've tested this change on one solid state and two mechanical drives.

[alc]

Here are the results from the test program that cycles through a physmem + 4 GB anonymous memory mapping on the following device:

ada3 at ahcich4 bus 0 scbus5 target 0 lun 0
ada3: <Samsung SSD 850 PRO 512GB EXM02B6Q> ACS-2 ATA SATA 3.x device
ada3: Serial Number S250NX0H626395F
ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada3: Command Queueing enabled
ada3: 488386MB (1000215216 512 byte sectors)
ada3: quirks=0x3<4K,NCQ_TRIM_BROKEN>

First-fit allocation:

len: 38619095040
run 0, 32s.276585056ns
run 1, 181s.419108154ns
run 2, 191s.817094537ns
run 3, 194s.971544762ns
run 4, 195s.463131329ns
run 5, 197s.429856809ns
run 6, 196s.777934962ns
run 7, 197s.896051113ns
run 8, 197s.904393671ns
run 9, 200s.373049926ns

Next-fit allocation:

len: 38619095040
run 0, 32s.829164766ns
run 1, 180s.354998174ns
run 2, 191s.766183886ns
run 3, 191s.574965677ns
run 4, 191s.881390396ns
run 5, 191s.433134603ns
run 6, 191s.595952462ns
run 7, 191s.558809195ns
run 8, 191s.262327156ns
run 9, 191s.221447187ns

[markj]

kern/subr_blist.c

181 ↗

(On Diff #29759)

The "skip" parameter to blst_radix_init() is still an int - should the type be updated there as it was for blst_meta_alloc()?

238 ↗

(On Diff #29759)

This assignment could be made unconditional.

472 ↗

(On Diff #29759)

This is an unrelated change with no functional impact, right?

[markj]

kern/subr_blist.c

472 ↗

(On Diff #29759)

Right, never mind, I hadn't noticed that you mentioned this in the description.

[alc]

kern/subr_blist.c

181 ↗

(On Diff #29759)

Yes. I was planning to address that in a separate change. Also, I don't care for the "1 +" term. This term exists because blst_radix_init() doesn't always account for a terminator.