From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mikulas Patocka Subject: Re: [PATCH 2/4] dm stats: support precise timestamps Date: Wed, 17 Jun 2015 09:17:40 -0400 (EDT) Message-ID: References: <20150616153345.GA1069@redhat.com> <20150617014324.GA30214@redhat.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: <20150617014324.GA30214@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Vivek Goyal Cc: Mike Snitzer , Laurence Oberman , Tao Ma , Robin Dong , dm-devel@redhat.com, Coly Li , "Alasdair G. Kergon" List-Id: dm-devel.ids On Tue, 16 Jun 2015, Vivek Goyal wrote: > On Tue, Jun 16, 2015 at 03:27:48PM -0400, Mikulas Patocka wrote: > > > > > > On Tue, 16 Jun 2015, Vivek Goyal wrote: > > > > > On Tue, Jun 09, 2015 at 05:21:39PM -0400, Mikulas Patocka wrote: > > > > > > [..] > > > > Messages > > > > ======== > > > > > > > > - @stats_create [ []] > > > > + @stats_create > > > > + [ ...] > > > > + [ []] > > > > > > > > Create a new region and return the region_id. > > > > > > > > @@ -48,6 +54,17 @@ Messages > > > > "/" - the range is subdivided into the specified > > > > number of areas. > > > > > > > > + > > > > + The number of optional arguments > > > > + > > > > + > > > > + The following optional arguments are supported > > > > + precise_timestamps - use precise timer with nanosecond resolution > > > > + instead of the "jiffies" variable. When this argument is > > > > + used, the resulting times are in nanoseconds instead of > > > > + milliseconds. Precise timestamps are a little bit slower > > > > + to obtain than jiffies-based timestamps. > > > > + > > > > > > Instead of "precise_timestams" will it make sense to call it > > > "nanosecond_timestamps" or "ns_timestamps". > > > > > > > > > > > > > > An optional parameter. A name that uniquely identifies > > > > the userspace owner of the range. This groups ranges together > > > > > > We are adding these new parameters/arguments in between existing parameters. > > > Will it break any of the existing scritps. Will it make sense to add these > > > new parameters at the end. It is more intuitive. > > > > It could break someone who uses number as program_id - but there is no > > program on Linux with name that is a pure number. > > > > There does not seem to be any restriction that program_id has to be > a valid program name. It could be any string. I used a program id > of 25 and it works. The purpose of program_id is that different programs don't step over each other's statistics. Your program should use the program name as program_id to make sure that it doesn't collide. > [root@tiger ~]# dmsetup message docker-docker--pool 0 @stats_create - /1 > 25 > 0 > > [root@tiger ~]# dmsetup message docker-docker--pool 0 @stats_create - /2 > 30 > 1 > > [root@tiger ~]# dmsetup message docker-docker--pool 0 @stats_list 25 > 0: 0+585465856 585465856 25 - > > [root@tiger ~]# dmsetup message docker-docker--pool 0 @stats_list > 0: 0+585465856 585465856 25 - > 1: 0+585465856 292732928 30 - > > May be we can introduce a new message to handle this new number of > arguments syntax. Say "stats_create_v2". That way existing programs > will not be broken, if any. There are no existing programs that use numbers as program_id. > > We can't add it at the end because program_id and aux_data are already > > optional arguments. > > > > > Also, I was wondering that why do we need to introduce this notion of > > > number of optional arguments. Can't we just introduce another optional > > > parameter [ns_timestamps]. That feels little simpler. > > > > Then, it will clash with program_id "ns_timestamps". Device mapper uses > > this "number of optional arguments" notation at other places, so I used it > > too, > > BTW, I have a very stupid question. This probably stems from the fact that > I don't know enough about dm argument parsing. > > Why can't I pass the argument in same format as command line. So how > about. > > @stats_create [program_id=] [aux_data=] > > That way we know what arguments are coming. There is no guessing and > handling optional parameters is easy too. Other dm targets don't use this style of argument passing. Mikulas > Thanks > Vivek >