From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurence Oberman Subject: Re: [PATCH 0/4] dm-latency: Introduction Date: Thu, 26 Feb 2015 12:00:47 -0500 (EST) Message-ID: <1377703243.9422950.1424970047797.JavaMail.zimbra@redhat.com> References: <54EEBFAF.4000002@gmail.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka Cc: Tao Ma , device-mapper development , Robin Dong , Coly Li , Alasdair Kergon List-Id: dm-devel.ids Mikulas Thanks This came from customer asking for support for similar functionality in proprietary solutions such as PowerPath and HDLM. I had seen the information from Coly Li and asked if he could submit for comments. I will look into what can be done with what is is /sys/block/dm-xxx/stat Laurence Oberman Red Hat Global Support Service SEG Team ----- Original Message ----- From: "Mikulas Patocka" To: "device-mapper development" , "Coly Li" Cc: "Tao Ma" , "Robin Dong" , "Laurence Oberman" , "Alasdair Kergon" Sent: Thursday, February 26, 2015 11:49:28 AM Subject: Re: [dm-devel] [PATCH 0/4] dm-latency: Introduction Hi We have already dm-statistics that counts various events - see Documentation/device-mapper/statistics.txt. It counts the nubmer of requests and the time spent servicing each request, thus you can calculate average latency from these values. Please look at dm-statistics to see if it fits your purpose. If you need additional information not provided by dm-statistics, it would be better to extend the statistics code rather than introduce new "latency" infrastructure. Mikulas On Thu, 26 Feb 2015, Coly Li wrote: > From: Coly Li > > 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 > > > > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel >