On Tue, May 14, 2013 at 02:44:53PM +0100, Joe Thornber wrote: > On Mon, May 13, 2013 at 11:23:04PM +0200, Pierre Beck wrote: > > Maybe I'm misunderstanding how the heuristics work - what makes mq > > pick a block for promotion? > > Hi Pierre, > > The mq policy is indeed very picky. The first thing I'd suggest is > you pick up my latest patches if you haven't already: > > http://device-mapper.org/patches/3.10/ Hm, it looks like all but two of the dmcache patches are in. The two patches to mq aren't (yet) there. > You just need the dm-cache*.patch ones, apply in the order given in > the series file. > > At it's heart mq is v. simple. It divides time up into slices called > 'ticks'. Hit counts are maintained for all blocks in the cache, and a > group of blocks that we're thinking of promoting. A cache/origin > block can only be hit once in each tick. When a candidate block's hit > count goes over a threshold it gets promoted. > > The threshold depends on the hit counts of the entries in the cache. > > At the moment hit counts don't degrade with time, that's something I > need to add to allow the cache to be more responsive to changing work > loads. > > > If you start with a discarded device (eg, you've run mkfs). Then the > cache should fill up v. quickly with my latest patches. Perhaps it > would be worth verifying this before you start investigating the > effects of sequential io? I'm also curious about what happens if, say, you have a discard-enabled zerofree that can "discard" just the unallocated blocks. That probably only helps if you can discard pieces big enough to fit one of dmcache's discard regions, right? --D > > - Joe > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
