Page MenuHomeFreeBSD

We only want to send the speedup to the lower layers when there's a shortage.
ClosedPublic

Authored by imp on Jan 15 2020, 1:11 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Jan 19, 8:37 PM
Unknown Object (File)
Thu, Jan 9, 5:48 AM
Unknown Object (File)
Dec 21 2024, 1:28 PM
Unknown Object (File)
Dec 10 2024, 6:11 AM
Unknown Object (File)
Nov 5 2024, 11:33 AM
Unknown Object (File)
Oct 20 2024, 9:11 AM
Unknown Object (File)
Oct 11 2024, 2:43 PM
Unknown Object (File)
Oct 6 2024, 9:58 AM
Subscribers
None

Details

Summary

Only send a speedup when there's a shortage. While this is a little racy, lost
races aren't a big deal for this function. If there's a shorage just popping up
after we check these values, then we'll catch it next time. If there's a
shortage that's just clearing up, we may do some work at the lower layers a
little sooner than we otherwise would have. Sicne shortages are relatively rare
events, both races are acceptable.

Test Plan

Without these, I'm seeing way too many speedups.

I tested this with:
dtrace -n 'fbt::softdep_send_speedup:entry {stack()}'

before the change, I saw it called all the time. After, it wasn't called at all.

Thanks for chuck for noticing the myriad of issues here. Other reviews will fix the other ones.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable