All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinz Mauelshagen <heinzm@redhat.com>
To: "dm-devel >> device-mapper development" <dm-devel@redhat.com>
Subject: Fwd: Re: dm-cache with zero hit rate
Date: Fri, 02 Aug 2013 20:19:07 +0200	[thread overview]
Message-ID: <51FBF81B.7090700@redhat.com> (raw)
In-Reply-To: <51FBF2FD.10205@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]




-------- Original Message --------
Subject: 	Re: dm-cache with zero hit rate
Date: 	Fri, 02 Aug 2013 19:57:17 +0200
From: 	Heinz Mauelshagen <heinzm@redhat.com>
To: 	Steinar H. Gunderson <sgunderson@bigfoot.com>



On 08/02/2013 03:58 PM, Steinar H. Gunderson wrote:
> On Fri, Aug 02, 2013 at 09:23:44AM -0400, Mike Snitzer wrote:
>> Yes, it is surprising.  Curious to know if the promotions aren't
>> happening due to the IO scheduler somehow merging all your random small
>> IO.  We don't yet have a descrete counter to show the number of
>> migrations that were skipped due to sequential_threshold but that is
>> something we can add.
>>
>> But you can effectively disable the sequential_threshold by setting it
>> really high, e.g.:
>>
>> dmsetup message cache 0 sequential_threshold 16384
> I tried this, and it still doesn't appear to promote anything at all:
>
> cache: 0 23440891904 cache 913/8192 0 7021239 0 2049048 0 0 0 0 0 2 migration_threshold 2048 4 random_threshold 8 sequential_threshold 16384
>
> It's only been running for a few minutes, though.
>
> FWIW, earlier I ran it on only one single partition, and then it worked.
> So it's not like my kernel is completely broken, at least.

Doesn't seem so.

Because you succeeded on a partition, mind trying a small some GB mapping
with smaller block size too on top of your big RAID? Eventually apply
the config you
used for your to your partition and adjust that to your large RAID?

If that fails as well, it looks like some strange device specific issue
causing the failure.
If it succeeds, it seems to be a large size related one.

Heinz

>
>> Please write a file that is smaller than your specified
>> sequential_threshold, and then read it numerous times via direct IO,
>> e.g.:
>>
>> dd if=<your file> of=/dev/null iflag=direct bs=16K
> I did, with a 16 kB file (that should certainly be small enough, right?),
> executing the dd command 10000 times. Still nothing cached.
>
> /* Steinar */




[-- Attachment #1.2: Type: text/html, Size: 3197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



           reply	other threads:[~2013-08-02 18:19 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <51FBF2FD.10205@redhat.com>]

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=51FBF81B.7090700@redhat.com \
    --to=heinzm@redhat.com \
    --cc=dm-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.