doc: Add requirements for sequential cutoff #699
Conversation
robertbaldyga
force-pushed
the
req-seq-cutoff
branch
from
0a58db8 to
aa34d5b
Compare
robertbaldyga
force-pushed
the
req-seq-cutoff
branch
from
aa34d5b to
69a655a
Compare
robertbaldyga
force-pushed
the
req-seq-cutoff
branch
from
69a655a to
1e19b5e
Compare
robertbaldyga
force-pushed
the
req-seq-cutoff
branch
from
1e19b5e to
ba5e059
Compare
Signed-off-by: Robert Baldyga <robert.baldyga@intel.com>
robertbaldyga
force-pushed
the
req-seq-cutoff
branch
from
ba5e059 to
335f830
Compare
| id: operation | ||
| --- | ||
|
|
||
| The sequential cutoff shall detect streams of sequential IO requests. |
There was a problem hiding this comment.
This looks like a bad requirement - impossible do verify
| --- | ||
|
|
||
| When lenght of the stream reaches the cutoff threshold, each next IO request | ||
| which continues the stream and is not full dirty hit shall be handled |
There was a problem hiding this comment.
You are not mentioning the fact, that sequential cutoff needs to be armed (you called it "enabled" in "policy_full").
There was a problem hiding this comment.
I think it would make sense to split this requirement into three, describing cutoff behaviour for all the policies. "full" and "always" would be extension of this requirement, adding the condition for cutoff triggering in case of "full". This way the requirement would be subject to verification.
| When number of IO requests accounted to given per-CPU stream reaches | ||
| the promotion count or stream length reaches the threshold, the stream | ||
| shall be promoted to shared stream pool. |
There was a problem hiding this comment.
this also is not verfiable - better to state that after reaching promotion threshold the other CPUs will recognize a stream initiated on its origin CPU
5 participants
Signed-off-by: Robert Baldyga robert.baldyga@intel.com