Page MenuHomeFreeBSD

RCTL disk io limits.
ClosedPublic

Authored by trasz on Jan 26 2016, 11:34 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Mar 3, 5:08 AM
Unknown Object (File)
Feb 23 2024, 10:45 PM
Unknown Object (File)
Jan 12 2024, 5:58 AM
Unknown Object (File)
Jan 9 2024, 12:38 AM
Unknown Object (File)
Dec 13 2023, 10:23 PM
Unknown Object (File)
Nov 28 2023, 1:09 PM
Unknown Object (File)
Nov 26 2023, 4:20 PM
Unknown Object (File)
Nov 19 2023, 1:55 AM

Details

Summary

Add four new RCTL resources - readbps, readiops, writebps and writeiops,
for limiting disk (actually filesystem) IO.

Note that in some cases these limits are not quite precise. It's ok,
as long as it's within some reasonable bounds.

Diff Detail

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

Event Timeline

trasz retitled this revision from to RCTL disk io limits..
trasz updated this object.
trasz edited the test plan for this revision. (Show Details)
wblock added inline comments.
usr.bin/rctl/rctl.8
316 ↗(On Diff #12715)

Break into two sentences, remove unneeded "just" and "the":

counters are only approximations.
Like
320 ↗(On Diff #12715)

Please do not use contractions.
"Difficult" is probably better than "hard".
"accounted for in" is clunky. Maybe "calculated in"?

they are accounted for in the filesystem layer, where it is difficult
trasz edited edge metadata.

Man page updates, suggested by wblock@.

trasz edited edge metadata.

One more man page tweak.

usr.bin/rctl/rctl.8
317 ↗(On Diff #12873)

Just "Like", not "Like the".

trasz edited edge metadata.

One more doc fix.

Nice, does this allow effectively limiting upload speed since the io can be limited? What about mmap?

Yes, it allows for limiting upload/download speed, asssuming it fits the RCTL subject:subject-id: model. Yes, it handles reads and writes from/to mmapped regions as well.

trasz edited edge metadata.

Regenerate.

wblock added a reviewer: wblock.

Man page looks good. Please remember to check with igor -R and mandoc -Tlint. Thanks!

This revision is now accepted and ready to land.Mar 17 2016, 10:04 PM
trasz edited edge metadata.

Major cleanup - some things were fixed, some committed to HEAD and looped
back; %CPU handling was removed altogether due to being to buggy.

This revision now requires review to proceed.Apr 5 2016, 1:00 PM

Note that in some cases these limits are not quite precise. It's ok, as long as it's within some reasonable bounds.

This comment could use clarification -- what's the it's in "it's within some reasonable bounds"? E.g., the limits are applied on a "best effort" basis and achieved disk I/O numbers may actually be (much?) higher (or lower?) -- under what conditions? etc.

This revision was automatically updated to reflect the committed changes.

Well, it's explained somewhat better in the manual page, but there are several aspects here.

First, at the filesystem layer we don't really have a way to count IOPS, as they happen at the device layer, ie below. We kind of estimate them.

Second, for writes we actually do the accounting for writes to the filesystem cache. (Mostly.)

Third, there are problem like whether to take readahead into account or not (my current stance is yeah, account it as reads).

Generally speaking, the meaning of this comment is that "reasonable bounds" are just what one might expect: the statistics might be, say, 10% off, but in a predictable and consistent way.

Generally speaking, the meaning of this comment is that "reasonable bounds" are just what one might expect: the statistics might be, say, 10% off, but in a predictable and consistent way.

Well, that's what I meant with the question -- what are reasonable bounds? 10%? 100%? I think everyone understands that it's an approximation, but there's no guidance on what the actual bounds look like.