From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:60197 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753335AbcKITen (ORCPT ); Wed, 9 Nov 2016 14:34:43 -0500 Date: Wed, 9 Nov 2016 11:34:41 -0800 From: Christoph Hellwig To: Jeff Moyer Cc: Christoph Hellwig , "Dan J. Williams" , linux-nvdimm@ml01.01.org, linux-block@vger.kernel.org Subject: Re: [patch] nd_blk,nd_pmem,nd_btt: add endio blktrace events Message-ID: <20161109193441.GA17343@infradead.org> References: <20161109191715.GA20314@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On Wed, Nov 09, 2016 at 02:31:30PM -0500, Jeff Moyer wrote: > bio_endio is still called for request_fn drivers, so you'd see two > completion events for those drivers if we did that, no? We'd see the bio_endio trace in addition to the request one, but they are at different granularities. Similar to how on the issue side we have trace_block_bio_queue for each bio, and trace_block_rq_issue for each request. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [patch] nd_blk,nd_pmem,nd_btt: add endio blktrace events Date: Wed, 9 Nov 2016 11:34:41 -0800 Message-ID: <20161109193441.GA17343@infradead.org> References: <20161109191715.GA20314@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Jeff Moyer Cc: Christoph Hellwig , linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org, linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-nvdimm@lists.01.org On Wed, Nov 09, 2016 at 02:31:30PM -0500, Jeff Moyer wrote: > bio_endio is still called for request_fn drivers, so you'd see two > completion events for those drivers if we did that, no? We'd see the bio_endio trace in addition to the request one, but they are at different granularities. Similar to how on the issue side we have trace_block_bio_queue for each bio, and trace_block_rq_issue for each request.