Re: Another cache target

[thornber@redhat.com]

On Thu, Dec 13, 2012 at 06:34:25PM -0800, Darrick J. Wong wrote:
> Actually, I decided to try out "mru" and see what it would do (or not do).  My
> current theory is that mq doesn't seem to like putting blocks in the cache
> until after you write 'em(?)  There's no way to spit out the cache stats while
> it's running, so it's difficult to make observations.
> 
> The "exerciser" is called maxiops, from:
> http://djwong.org/programs/bogodisk/bogoseek-0.6.2.tar.gz
> 
> untar, make, ./maxiops /dev/somethingorother -b 4096
> 
> The third column of output is a rough estimate of iops.  maxiops is really just
> an aio port of bogoseek -n, which is in the same package.  If you want to do a
> destructive write test with them, pass -w.


The mq policy is very conservative, designed to slowly move frequently
accessed blocks into the cache.  I'm going to provide another policy
that's simpler, but much more aggressive about caching writes and
constantly cleaning blocks in the background.

There are a couple of reasons why mq may have decided not to cache
your blocks:

i) They just aren't being hit very frequently.

ii) It's decided that you're doing a big linear read/write, and so is
not updating it's hit stats.  Vivek Goyal put this code in for us and
it's been a big win in the testing I've done.  The rationale being
that spindles are often very good at doing v. large contiguous io.

The threshold for deciding what is linear/random io is configurable.

You may also want to experiment with discarding all data at the start
of your test (eg, as mkfs does).  In this case mq is aware that
promoting a block to the cache is very cheap because no copying is
needed, and as such will promote much sooner.

I'll add some tests to my test suite that use your maxiops program and
see if I can work out what's going on.

- Joe