| Rule #1.
If you're going to have enough paging I/O to signficantly
affect performance, the system would benefit more from having
more memory.
Beyond Rule #1.
Just guessing, the things that might help more than putting
a small cache in front of the page/swap device(s) would be:
o Spread the paging I/O out over multiple disks and
controllers/adapters. Even with Digital UNIX not
using the old Berkeley striped page/swap space
algorithms, more heads and data paths may be able
to support more paging I/O.
o Use Striping. A controller based stripe set may support
more bandwidth and requests per second than a single
disk. A host based stripe set can often beat the
the performance of a controller based one.
Will a cache help writes?
Usually. Under all but the heaviest I/O loads, the WBC on the
HSZ can absorb writes and in whatever idle time exists, get
them to disk. Until the cache is saturated, the write performance
is quite good. For paging writes, this should help. For swapping
performance, it depends on how much data is being swapped. As
soon as the cache fills up it doesn't help much, though it can
still improve the performance of RAID-5 under it by converting
it to RAID-3.
Will a cache help reads?
Maybe. If a pageing write generally results in the data being
flushed from memory, then the cache could have some value. Without
a copy in host memory, a copy in cache memory will make it faster
to read back.
Once a page is written how likely is to be read back soon after
it was written? If not "soon", then it seems likely that the
later writes will replace the older data in the cache. Since
the paging code probably prefers to write idle pages, those
which haven't been reference in a long time, there is an assumption
that also won't be needed soon. When this isn't the case, then
the system is probably thrashing and attention to Rule #1 is in
order.
Since a page-out is often accompanied by a page-in, will the
controller elect to cache the just read data in preference to
the slightly older recently written data (I hope not)? If not,
then there is some hope that the older data is still around in
the cache.
Will a cache hurt reads?
If it happens that cache hits on a page/swap device are
very rare, then caching might hurt a little. It takes the
controller some time to see if a range of data is in the
cache. The difference might not be noticable, but if it
is it affects all the other I/O on that same controller.
Will a cache hurt writes?
Probably no more than what it does when read data isn't
cached. If the cache is saturated, then the data will
still be written to the cache as the older data is flushed.
It may still help a little.
Lies, ____ed lies and statistics...
Taking a guess, if the paging system isn't thrashing, the
sort of data that would benefit from a cache is not the
data the virtual memory subsystem will be paging back in.
Of the various ways to improve paging and swapping performance,
a small device cache is the last I would look at.
But, when that is the only choice, then a benchmark is
probably in order. If you can isolate a test that causes
paging and is fairly consistent in its run-time, then you
can benchmark the test with and without the cache.
|
| Dr. File System is (as usual!) an admirable source of advice. Just one
small point I'd add based on my much more limited IO performance
experience...
> o Use Striping. A controller based stripe set may support
> more bandwidth and requests per second than a single
> disk. A host based stripe set can often beat the
> the performance of a controller based one.
I think this is true *only* if you have CPU time to spare on the host.
When I played with this under another (two letter) operating system,
host-based striping was faster but definitely cost additional CPU time
on the host.
For workloads that consume a lot of host CPU time, you may prefer to
delegate the striping details off to the controller, and let the host
CPU worry about running user programs.
/john
|