From: Coly Li <i@coly.li>
To: dm-devel@redhat.com
Cc: Tao Ma <boyu.mt@taobao.com>, Robin Dong <sanbai@alibaba-inc.com>,
Laurence Oberman <loberman@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: [PATCH 0/4] dm-latency: Introduction
Date: Tue, 24 Feb 2015 01:27:43 +0800 [thread overview]
Message-ID: <54EB630F.2070403@coly.li> (raw)
From: Coly Li <bosong.ly@alibaba-inc.com>
Dm-latency patch set is an effort to measure hard disk I/O latency on
top of device mapper layer. The original motivation of I/O latency
measurement was to predict hard disk failure by machine learning method,
I/O latency information was one of the inputs sent to machine learning
model.
This patch set was written in Aug~Sep 2013, I deployed it on many
servers of Alibaba cloud infrastructure. After running for weeks, some
interesting data about hard disk I/O latency was observed. In 2013, I
gave a talk on OpenSuSE Conference about this topic
(http://blog.coly.li/docs/osc13-coly.pdf).
When generating time stamp for I/O request, clock source is a global
unique resource which is protected by spin-locks. Dm-latency was tested
on SAS/SATA hard disk and SATA SSD, it worked well as expected. Running
dm-latency on PCI-e or NVMe SSD should work (I didn't test), but there
will be spin-lock scalability issue, when accessing clock source for
time stamping.
Dm-latency is good for I/O latency measurement to hard disk based
storage, no matter local or distributed storage via network. For PCI-e
or NVMe SSD, I suggest people to look for device provided statistic
information, if there is.
The code is very simple, there is no resource allocation/destory, no
spin_lock/spin_unlock. The patch set gets merged into Alibaba kernel
more than 1 year, no bug reported in last 12 months.
This patch set has 4 patches,
- [PATCH 1/4] dm-latency: move struct mapped_device from dm.c to dm.h
- [PATCH 2/4] dm-latency: add I/O latency measurement in device mapper
- [PATCH 3/4] dm-latency: add sysfs interface
- [PATCH 4/4] dm-latency: add reset function to dm-latency in sysfs
interface
All these patches are rebased on Linux 4.0-rc1.
Today Laurence Oberman from Redhat sent me an email asking whether this
patch set is upstream merged, because he is thinking of pulling this
patch set into their kernel. I'd like to maintain this patch set, hope
it could be merged.
Thanks in advance.
Coly Li
next reply other threads:[~2015-02-23 17:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 17:27 Coly Li [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-02-26 6:39 [PATCH 0/4] dm-latency: Introduction Coly Li
2015-02-26 16:49 ` Mikulas Patocka
2015-02-26 17:00 ` Laurence Oberman
2015-02-26 17:39 ` Bryn M. Reeves
2015-02-26 17:25 ` Bryn M. Reeves
2015-02-26 19:34 ` Mikulas Patocka
2015-02-26 19:45 ` Laurence Oberman
2015-02-27 10:23 ` Bryn M. Reeves
2015-02-27 19:13 ` Mikulas Patocka
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=54EB630F.2070403@coly.li \
--to=i@coly.li \
--cc=agk@redhat.com \
--cc=boyu.mt@taobao.com \
--cc=dm-devel@redhat.com \
--cc=loberman@redhat.com \
--cc=sanbai@alibaba-inc.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.