mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Amit Kale <amitkale@geeksofpune.in>
To: OS Engineering <osengineering@stec-inc.com>
Cc: "koverstreet@google.com" <koverstreet@google.com>,
	"linux-bcache@vger.kernel.org" <linux-bcache@vger.kernel.org>,
	"thornber@redhat.com" <thornber@redhat.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Padmini Balasubramaniyan <padminib@stec-inc.com>,
	Amit Phansalkar <aphansalkar@stec-inc.com>
Subject: Re: Performance Comparison among EnhanceIO, bcache and dm-cache.
Date: Wed, 12 Jun 2013 10:28:03 +0530	[thread overview]
Message-ID: <201306121028.03278.amitkale@geeksofpune.in> (raw)
In-Reply-To: <D399C715A2AD7F4F891A75871FC3117507866B@MYMBX3.stec-inc.ad>

On Tuesday 11 Jun 2013, OS Engineering wrote:
> Hi Jens,
> 
> In continuation with our previous communication, we have carried out
> performance comparison among EnhanceIO, bcache and dm-cache.
> 
> We found that EnhanceIO provides better throughput on zipf workload (with
> theta=1.2) in comparison to bcache and dm-cache for write through caches.
> However, for write back caches, we found that dm-cache had best throughput
> followed by EnhanceIO and then bcache. Dm-cache commits on-disk metadata
> every time a REQ_SYNC or REQ_FUA bio is written. If no such requests are
> made then it commits metadata once every second. If power is lost, it may
> lose some recent writes. However, EnhanceIO and bcache do not acknowledge
> IO completion until both IO and metadata hits the SSD. Hence, EnhanceIO
> and bcache provide higher data integrity at a cost of performance.

So it won't be fair to compare them with dm-cache in write-back mode since 
guarantees are different. I am sure if similar (SYNC/FUA enforcement for 
persistence) guarantees are implemented in bcache/EnhanceIO, they'll offer a 
much better performance. 

> 
> The fio config and setup information follows:
> HDD              : 100GB
> SSD              :  20GB
> Mode             : write through / write back
> Cache block_size : 4KB for bcache, EnhanceIO and 256KB for dm-cache
> 
> The other options have been left to their default values.
> 
> Note:
> 1) In case of dm-cache, we used 2 partitions of same SSD with 1GB partition
> as metadata and 20GB partition as caching device. This has been done so as
> to ensure a fair comparison as EnhanceIO and bcache do not have a separate
> metadata device.
> 
> 2) In order to ensure proper cache warm up, We have turned off sequential
> bypass in bcache. This does not impact our performance results as they are
> taken for random workload.
> 
> For each test, we first performed a warm up run using the following fio
> options: fio --direct=1 --size=90% --filesize=20G --blocksize=4k
> --ioengine=libaio --rw=rw --rwmixread=100 --rwmixwrite=0 --iodepth=8 ...
> 
> Then, we performed our actual run with the following fio options:
> fio --direct=1 --size=100% --filesize=20G --blocksize=4k --ioengine=libaio
> --rw=randrw --rwmixread=90 --rwmixwrite=10 --iodepth=8 --numjobs=4
> --random_distribution=zipf:1.2 ...

Did you experiment a little with varying iodepth and numjobs? Is this the best 
combination you found out? The numbers below appear low considering a 90% hit 
ratio for EnhanceIO. SSD baseline performance shown below appears low. However 
it should not affect this comparison. All caching solutions are being subjected 
to the same ratio of HDD/SSD performance.

> 
> ============================= Write Through ===============================
> Type      Read Latency(ms)   Write Latency(ms)    Read(MB/s)    Write(MB/s)
> ===========================================================================
> EnhanceIO      1.58              16.53               32.91       3.65
> bcache         0.58              31.05               27.17       3.02
> dm-cache       0.24              27.45               31.05       3.44

EnhanceIO shows much higher read latency here. Is that because of READFILLs ? 
Write latency, read-write throughputs are good.

> 
> ============================= Write Back ==================================
> Type      Read Latency(ms)    Write Latency(ms)    Read(MB/s)   Write(MB/s)
> ===========================================================================
> EnhanceIO      0.34               4.98               138.72      15.40
> bcache         0.95               1.76               106.82      11.85
> dm-cache       0.58               0.55               193.76      21.52

Here EnhanceIO's read latency is better compared the other two. Write latency 
is larger than the other two. 

-Amit

> 
> ============================ Base Line ====================================
> Type      Read Latency(ms)    Write Latency(ms)    Read(MB/s)   Write(MB/s)
> ===========================================================================
> HDD            6.22              27.23                13.51       1.49
> SSD            0.47               0.42               235.87      26.21
> 
> We have written scripts that aid in cache creation, deletion and
> performance run for all these caching solutions. These scripts can be
> found at:
> https://github.com/stec-inc/EnhanceIO/tree/master/performance_test
> 
> Thanks and Regards,
> sTec Team
> 
> PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
> 
> This electronic transmission, and any documents attached hereto, may
> contain confidential, proprietary and/or legally privileged information.
> The information is intended only for use by the recipient named above. If
> you received this electronic message in error, please notify the sender
> and delete the electronic message. Any disclosure, copying, distribution,
> or use of the contents of information received in error is strictly
> prohibited, and violators will be pursued legally. --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2013-06-12  4:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 15:05 OS Engineering
2013-06-12  4:58 ` Amit Kale [this message]
2013-06-12 11:39   ` OS Engineering
2013-06-17 10:29 ` Joe Thornber
2013-06-18 16:30   ` [dm-devel] " Michael Fortson
     [not found] ` <CAMM=eLfKku3CuHUS-0Akv=FdEzk_OWz3j+3oTAWCrFnFLZ0b1g@mail.gmail.com>
2013-07-02  8:25   ` OS Engineering

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=201306121028.03278.amitkale@geeksofpune.in \
    --to=amitkale@geeksofpune.in \
    --cc=aphansalkar@stec-inc.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=koverstreet@google.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osengineering@stec-inc.com \
    --cc=padminib@stec-inc.com \
    --cc=thornber@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

all inboxes | Powered by JetHome®