Page MenuHomeFreeBSD

buf: Fix the dirtybufthresh check
ClosedPublic

Authored by markj on Feb 23 2021, 5:07 PM.
Tags
None
Referenced Files
F81665267: D28901.id84677.diff
Fri, Apr 19, 4:23 PM
F81618287: D28901.id84562.diff
Fri, Apr 19, 1:39 AM
Unknown Object (File)
Thu, Apr 4, 1:24 AM
Unknown Object (File)
Sun, Mar 31, 8:15 PM
Unknown Object (File)
Feb 29 2024, 1:46 PM
Unknown Object (File)
Feb 21 2024, 11:39 PM
Unknown Object (File)
Feb 13 2024, 8:24 PM
Unknown Object (File)
Feb 10 2024, 6:02 PM
Subscribers

Details

Summary

dirtybufthresh is a watermark, slightly below the high watermark for
dirty buffers. When a delayed write is issued, the dirtying thread will
start flushing buffers if the dirtybufthresh watermark is reached. This
helps ensure that the high watermark is not reached, otherwise
performance will degrade as clustering and other optimizations are
disabled (see buf_dirty_count_severe()).

When the buffer cache was partitioned into "domains", the dirtybufthresh
threshold checks were not updated. Fix this.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 37322
Build 34211: arc lint + arc unit

Event Timeline

markj requested review of this revision.Feb 23 2021, 5:07 PM
This revision is now accepted and ready to land.Feb 23 2021, 6:19 PM

LGTM.

I guess this case is intended for when a single-ish writer is outpacing the buf daemon?

I guess this case is intended for when a single-ish writer is outpacing the buf daemon?

Kind of, yes.

This case is problematic mostly not because we kept a lot of buffers for buffer daemon to flush, but because the daemon cannot flush it at all. We own the vnode lock, which prevents buffer daemon from initiating the writes for our dirty delayed-write buffers, so we must help it.

It appears that this change should be MFC'ed to 12.

This revision was automatically updated to reflect the committed changes.