linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: Zdenek Kabelac <zkabelac@redhat.com>
Cc: Mcdermott <scott@smemsh.net>,
	Scott,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] when bringing dm-cache online, consumes all memory and reboots
Date: Tue, 24 Mar 2020 23:35:12 +0100	[thread overview]
Message-ID: <da1ff669e1f69c4f02c10dc4726190d9@assyoma.it> (raw)
In-Reply-To: <4f10a1a7-0dc4-0e66-641d-62176f26614e@redhat.com>

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?

> Yeah - if you read only 'directory' metadata structures - it's
> perfectly OK with caching, if you do a full data read of the whole
> storage it's not going to help (which is what I've meant).
> 
> The main message is - cache is there to accelerate often read disk 
> blocks.
> If there is no hotspot and disk is mostly read over the whole address
> space equally there will be no big benefit of cache usage.
> 
> However main message should be - user should think about sizes of 
> caching
> devices and its implications - there is no universal setting that fits
> best all users.

Sure.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2020-03-24 22:35 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 [this message]
2020-03-25  8:55               ` Zdenek Kabelac
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=da1ff669e1f69c4f02c10dc4726190d9@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=scott@smemsh.net \
    --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).