Lines Matching refs:Of
5 % it under the terms of the GNU General Public License as published by
6 % the Free Software Foundation; either version 2 of the License, or
10 % but WITHOUT ANY WARRANTY; without even the implied warranty of
14 % You should have received a copy of the GNU General Public License
42 example usages of it in everyday work here at OSLO's Scalability and
61 sector number and IO size (number of sectors). Using this information,
84 to be used in the next phase of the workload processing.
86 \item Once \texttt{btrecord} has successfully created a series of data
92 The major characteristics of the IO stream that are kept intact include:
102 \item[IO size] The same number of sectors are transferred.
105 \texttt{blktrace} run are used to determine the amount of time between
115 during replays. In addition the actual ordering of IOs \emph{between}
117 maintains its own concept of time, and thus there may be slippage of the
123 guaranteeing correct ordering of IOs across all devices, resulted in
127 \subsection{\texttt{btrecord/btreplay} Method of Operation}
131 entrance of IOs into the block IO layer. In order to replay these IOs with
133 multiple sequential (in time) IOs and put them in a single \emph{bunch} of
135 kernel\footnote{Attempts to do them individually resulted in too large of a
137 number of workloads, the IOs are coming in from the page cache handling
139 time intervals between issues.}. To manage the size of the \emph{bunches},
143 \item[\texttt{--max-bunch-time}] This is the amount of time to encompass
158 about \emph{bunches} of IOs to be replayed. \texttt{btreplay} operates on
159 these record data files by spawning a new pair of threads per file. One
160 thread manages the submitting of AIOs per bunch in the record data file,
165 Each submitting thread simply reads the input file of \emph{bunches}
167 ordering and timing of IOs seen during the sample workload. The reclaiming
171 The number of CPUs being used on the replay system can be different from
174 system to utilize. If the number of CPUs on the replay system is less than
176 overload of CPU processing capabilities on the replay system. (Refer to
182 The overall known deficiencies with this current set of utilities is
187 \item Lack of IO ordering across devices.
190 \emph{We could institute the notion of global time across threads,
195 \item Lack of IO timing accuracy -- additional time between IO bunches.
204 \item Bunching of IOs results in reduced time amongst IOs within a bunch.
209 \texttt{-max-pkts=1} and then each IO would be treated individually. Of
210 course, this would probably then run into the problem of excessive
214 \item 1-to-1 mapping of devices -- for now the devices on the replay
218 \emph{It should be relatively trivial to add in the notion of
221 machine\footnote{The notion of an offset and device size to replay on
226 \medskip\emph{One could also add in the notion of CPU mappings as well --
305 amount of time (in nanoseconds) to include in any one bunch of IOs that
306 are to be processed. The smaller the value, the smaller the number of
308 However, after a certain point the amount of overhead per bunch may result
317 maximum number of IOs to store in a single bunch. As with the \texttt{-m}
321 The default value is 8, with a maximum value of up to 512 being supported.
329 \item Device identifier (taken directly from the device name of the
344 This option will output some simple statistics at the end of a successful
346 an example of some output, while figure~\ref{fig:verb-defs}
366 \item[Field 2] The second field contains the total number of packets
369 \item[Field 3] The next field shows the number of packets eligible for
372 \item[Field 4] The fourth field contains the total number of IO bunches.
374 \item[Field 5] The last field shows the average number of IOs per bunch
406 \texttt{--cpus}\\Set Number of CPUs to Use}
445 \item Device identifier (taken directly from the device name of the
458 \texttt{--iterations}\\Set Number of Iterations to Run}
460 This option requires a single parameter which specifies the number of times
466 This option requires a single parameter which specifies the name of a
468 just two pieces of data per line:
488 -- we do not (yet?) support the notion of blank lines, or comment lines, or
505 to be used. If the value of two is used, then the stall time is
506 divided by half resulting in a reduction of the execution time by
508 be equivalent of not having stall.
515 performed by \texttt{btreplay}. The name of each file so created will be
516 the input file name used with an extension of \texttt{.rep} appended onto
517 it. Thus, an input file of the name \texttt{sdab.replay.3} would generate a
522 names of the input files being processed.
