Page MenuHomeFreeBSD

buf: Fix the dirtybufthresh check
ClosedPublic

Authored by markj on Feb 23 2021, 5:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 29, 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
Unknown Object (File)
Dec 23 2023, 4:37 AM
Unknown Object (File)
Dec 16 2023, 1:08 AM
Unknown Object (File)
Dec 12 2023, 12:15 PM
Unknown Object (File)
Dec 2 2023, 8:23 AM
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
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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.