linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>,
	thornber@redhat.com,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Testing the new LVM cache feature
Date: Fri, 30 May 2014 09:55:29 -0400	[thread overview]
Message-ID: <20140530135529.GC8830@redhat.com> (raw)
In-Reply-To: <20140530134642.GL1302@redhat.com>

On Fri, May 30 2014 at  9:46am -0400,
Richard W.M. Jones <rjones@redhat.com> wrote:

> I have now set both read_promote_adjustment ==
> write_promote_adjustment == 0 and used drop_caches between runs.
> 
> I also read Documentation/device-mapper/cache-policies.txt at Heinz's
> suggestion.
> 
> I'm afraid the performance of the fio test is still not the same as
> the SSD (4.8 times slower than the SSD-only test now).

Obviously not what we want.  But you're not doing any repeated IO to
those blocks.. it is purely random right?

So really, the cache is waiting for blocks to get promoted from the
origin if the IOs from fio don't completely cover the cache block size
you've specified.

Can you go back over those settings?  From your dmsetup table output you
shared earlier in the thread you're using a blocksize of 128 sectors (or
64K).  And your fio random write workload is using 64K.

So unless you have misaligned IO you _should_ be able to avoid reading
from the origin.  But XFS is in play here.. I'm wondering if it is
issuing IO differently than we'd otherwise see if you were testing
against the block devices directly...
 
> Would repeated runs of (md5sum virt.* ; echo 3 > /proc/sys/vm/drop_caches)
> not eventually cause the whole file to be placed on the SSD?
> It does seem very counter-intuitive if not.

If you set read_promote_adjustment to 0 it should pull the associated
blocks into the cache.  What makes you think it isn't?  How are you
judging the performance of the md5sum IO?  Do you see IO being issued to
the origin via blktrace or something?

  parent reply	other threads:[~2014-05-30 13:55 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 10:18 [linux-lvm] Testing the new LVM cache feature Richard W.M. Jones
2014-05-22 14:43 ` Zdenek Kabelac
2014-05-22 15:22   ` Richard W.M. Jones
2014-05-22 15:49     ` Richard W.M. Jones
2014-05-22 18:04       ` Mike Snitzer
2014-05-22 18:13         ` Richard W.M. Jones
2014-05-29 13:52           ` Richard W.M. Jones
2014-05-29 20:34             ` Mike Snitzer
2014-05-29 20:47               ` Richard W.M. Jones
2014-05-29 21:06                 ` Mike Snitzer
2014-05-29 21:19                   ` Richard W.M. Jones
2014-05-29 21:58                     ` Mike Snitzer
2014-05-30  9:04                       ` Richard W.M. Jones
2014-05-30 10:30                         ` Richard W.M. Jones
2014-05-30 13:38                         ` Mike Snitzer
2014-05-30 13:40                           ` Richard W.M. Jones
2014-05-30 13:42                           ` Heinz Mauelshagen
2014-05-30 13:54                             ` Richard W.M. Jones
2014-05-30 13:58                               ` Zdenek Kabelac
2014-05-30 13:46                           ` Richard W.M. Jones
2014-05-30 13:54                             ` Heinz Mauelshagen
2014-05-30 14:26                               ` Richard W.M. Jones
2014-05-30 14:29                                 ` Mike Snitzer
2014-05-30 14:36                                   ` Richard W.M. Jones
2014-05-30 14:44                                     ` Mike Snitzer
2014-05-30 14:51                                       ` Richard W.M. Jones
2014-05-30 14:58                                         ` Mike Snitzer
2014-05-30 15:28                                           ` Richard W.M. Jones
2014-05-30 18:16                                             ` Mike Snitzer
2014-05-30 20:53                                               ` Mike Snitzer
2014-05-30 13:55                             ` Mike Snitzer [this message]
2014-05-30 14:29                               ` Richard W.M. Jones
2014-05-30 14:36                                 ` Mike Snitzer
2014-05-30 11:53                       ` Mike Snitzer
2014-05-30 11:38                 ` Alasdair G Kergon
2014-05-30 11:45                   ` Alasdair G Kergon
2014-05-30 12:45                     ` Werner Gold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140530135529.GC8830@redhat.com \
    --to=snitzer@redhat.com \
    --cc=heinzm@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=rjones@redhat.com \
    --cc=thornber@redhat.com \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).