Page MenuHomeFreeBSD

RCTL disk io limits.
ClosedPublic

Authored by trasz on Jan 26 2016, 11:34 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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

trasz updated this revision to Diff 12715.Jan 26 2016, 11:34 AM
trasz retitled this revision from to RCTL disk io limits..
trasz updated this object.
trasz edited the test plan for this revision. (Show Details)
trasz added a reviewer: kib.Jan 26 2016, 11:35 AM
wblock added a subscriber: wblock.Jan 26 2016, 2:52 PM
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 updated this revision to Diff 12872.Jan 30 2016, 3:21 PM
trasz edited edge metadata.

Man page updates, suggested by wblock@.

trasz updated this revision to Diff 12873.Jan 30 2016, 3:23 PM
trasz edited edge metadata.

One more man page tweak.

wblock added inline comments.Jan 30 2016, 8:44 PM
usr.bin/rctl/rctl.8
317 ↗(On Diff #12873)

Just "Like", not "Like the".

trasz updated this revision to Diff 12953.Feb 2 2016, 3:19 PM
trasz edited edge metadata.

One more doc fix.

emaste added a subscriber: emaste.Feb 23 2016, 4:22 PM

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

trasz added a comment.Mar 10 2016, 5:27 PM

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 updated this revision to Diff 14352.Mar 16 2016, 8:30 AM
trasz edited edge metadata.

Regenerate.

wblock accepted this revision.Mar 17 2016, 10:04 PM
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 updated this revision to Diff 14886.Apr 5 2016, 1:00 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
emaste added a comment.Apr 5 2016, 1:28 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.
trasz added a comment.Apr 7 2016, 4:30 AM

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.

emaste added a comment.Apr 7 2016, 8:59 PM

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.