From: Jon Bernard <jbernard@tuxion.com>
To: Jack Wang <jack.wang.usish@gmail.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: poor thin performance, relative to thick
Date: Tue, 12 Jul 2016 23:29:41 -0400 [thread overview]
Message-ID: <20160713032926.GA30280@helmut> (raw)
In-Reply-To: <CA+res+RiK-qARGYgasWoLMTDXZ8RpF9eXy1uYUHxNSqJ6Joxfg@mail.gmail.com>
* Jack Wang <jack.wang.usish@gmail.com> wrote:
> 2016-07-11 22:44 GMT+02:00 Jon Bernard <jbernard@tuxion.com>:
> > Greetings,
> >
> > I have recently noticed a large difference in performance between thick
> > and thin LVM volumes and I'm trying to understand why that it the case.
> >
> > In summary, for the same FIO test (attached), I'm seeing 560k iops on a
> > thick volume vs. 200k iops for a thin volume and these results are
> > pretty consistent across different runs.
> >
> > I noticed that if I run two FIO tests simultaneously on 2 separate thin
> > pools, I net nearly double the performance of a single pool. And two
> > tests on thin volumes within the same pool will split the maximum iops
> > of the single pool (essentially half). And I see similar results from
> > linux 3.10 and 4.6.
> >
> > I understand that thin must track metadata as part of its design and so
> > some additional overhead is to be expected, but I'm wondering if we can
> > narrow the gap a bit.
> >
> > In case it helps, I also enabled LOCK_STAT and gathered locking
> > statistics for both thick and thin runs (attached).
> >
> > I'm curious to know whether this is a know issue, and if I can do
> > anything the help improve the situation. I wonder if the use of the
> > primary spinlock in the pool structure could be improved - the lock
> > statistics appear to indicate a significant amount of time contending
> > with that one. Or maybe it's something else entirely, and in that case
> > please enlighten me.
> >
> > If there are any specific questions or tests I can run, I'm happy to do
> > so. Let me know how I can help.
> >
> > --
> > Jon
>
> Hi Jon,
>
> Have you try to enable scsi_mq mode in newer kernel eg 4.6, see if it
> makes any difference?
Thanks for the suggestion, I had not tried it previously. I added
'scsi_mod.usb_blk_mq=Y' and 'dm_mod.use_blk_mq=Y' to my kernel command
line and verified the mq subdirectory contents in /sys/block/<device>.
All seemed to be correctly enabled. I also realized that
dm_mod.use_blk_mq is only for multipath, so I don't think it's relevant
to my tests.
Results were very similar to previous tests, ~10x slowdown from thick to
thin. Mike raised several good points, I'm re-running the tests and
will post new results in response.
--
Jon
next prev parent reply other threads:[~2016-07-13 3:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-11 20:44 poor thin performance, relative to thick Jon Bernard
2016-07-12 8:28 ` Jack Wang
2016-07-13 3:29 ` Jon Bernard [this message]
2016-07-13 14:17 ` Mike Snitzer
2016-07-12 8:30 ` Zdenek Kabelac
2016-07-13 4:00 ` Jon Bernard
2016-07-12 18:46 ` Mike Snitzer
2016-07-14 4:21 ` Jon Bernard
2016-07-14 20:58 ` Mike Snitzer
2016-07-15 18:59 ` Mike Snitzer
2016-07-15 20:57 ` Jon Bernard
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=20160713032926.GA30280@helmut \
--to=jbernard@tuxion.com \
--cc=dm-devel@redhat.com \
--cc=jack.wang.usish@gmail.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.