linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: Scott Mcdermott <scott@smemsh.net>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] when bringing dm-cache online, consumes all memory and reboots
Date: Wed, 25 Mar 2020 09:55:10 +0100	[thread overview]
Message-ID: <26bc2a80-466c-18d5-2d7f-4877c05e172c@redhat.com> (raw)
In-Reply-To: <da1ff669e1f69c4f02c10dc4726190d9@assyoma.it>

Dne 24. 03. 20 v 23:35 Gionatan Danti napsal(a):
> Il 2020-03-24 16:09 Zdenek Kabelac ha scritto:
>> In past we had problem that when users have been using huge chunk size,
>> and small 'migration_threashold' - the cache was unable to demote chunks
>> from the cache to the origin device� (the size of 'required' data for
>> demotion were bigger then what has been allowed by threshold).
>>
>> So lvm2/libdm implemented protection to always set at least 8 chunks
>> is the bare minimum.
>>
>> Now we face clearly the problem from 'the other side' - users have way
>> too big chunks (we've seen users with 128M chunks) - and so threshold
>> is set to 1G
>> and users are facing serious bottleneck on the cache side doing to many
>> promotions/demotions.
>>
>> We will likely fix this by setting max chunk size somewhere around 2MiB. >
> Thanks for the explanation. Maybe is a naive proposal, but can't you simply 
> set migration_threshold equal to a single chunk for >2M sized chunks, and 8 
> chunks for smaller ones?

Using large cache chunks likely degrades the usefulness and purpose of cache.
Though we are missing some comparative tables showing how the
optimal layouts should look like.

So the idea is not to just 'let it somehow work' but rather to move it towards
more efficient usage of available resources.

Zdenek

  reply	other threads:[~2020-03-25  8:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22 17:57 [linux-lvm] when bringing dm-cache online, consumes all memory and reboots Scott Mcdermott
2020-03-23  8:26 ` Joe Thornber
2020-03-23  9:57   ` Zdenek Kabelac
2020-03-23 16:26     ` John Stoffel
2020-03-23 22:02     ` Scott Mcdermott
2020-03-24  9:43       ` Zdenek Kabelac
2020-03-24 11:37         ` Gionatan Danti
2020-03-24 15:09           ` Zdenek Kabelac
2020-03-24 22:35             ` Gionatan Danti
2020-03-25  8:55               ` Zdenek Kabelac [this message]
2020-03-23 21:35   ` Scott Mcdermott

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=26bc2a80-466c-18d5-2d7f-4877c05e172c@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=scott@smemsh.net \
    /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).