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.
Details
Details
- Reviewers
kib wblock - Group Reviewers
manpages - Commits
- rS297633: Add four new RCTL resources - readbps, readiops, writebps and writeiops,
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 3132 Build 3165: arc lint + arc unit
Event Timeline
| usr.bin/rctl/rctl.8 | ||
|---|---|---|
| 309 | Break into two sentences, remove unneeded "just" and "the": counters are only approximations. Like | |
| 313 | Please do not use contractions. they are accounted for in the filesystem layer, where it is difficult | |
| usr.bin/rctl/rctl.8 | ||
|---|---|---|
| 310 | Just "Like", not "Like the". | |
Comment Actions
Nice, does this allow effectively limiting upload speed since the io can be limited? What about mmap?
Comment Actions
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.
Comment Actions
Man page looks good. Please remember to check with igor -R and mandoc -Tlint. Thanks!
Comment Actions
Major cleanup - some things were fixed, some committed to HEAD and looped
back; %CPU handling was removed altogether due to being to buggy.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.