From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH 8/7] blktrace: support discard requests Date: Wed, 13 Aug 2008 13:17:40 +0200 Message-ID: <20080813111740.GA20055@kernel.dk> References: <1218299181.26926.88.camel@pmac.infradead.org> <1218364148.5063.30.camel@pmac.infradead.org> <1218364862.5063.43.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Ric Wheeler , linux-fsdevel@vger.kernel.org, gilad@codefidence.com, matthew@wil.cx To: David Woodhouse Return-path: Received: from brick.kernel.dk ([87.55.233.238]:17292 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752083AbYHMLRn (ORCPT ); Wed, 13 Aug 2008 07:17:43 -0400 Content-Disposition: inline In-Reply-To: <1218364862.5063.43.camel@pmac.infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Aug 10 2008, David Woodhouse wrote: > While doing this, I note blktrace doesn't handle partial completion > particularly well. Since our FTL implementations currently don't care > about merged requests and just call end_request(), we see this (note the > sector counts in the completion events, which _should_ all be '+ 16')... > 44,0 0 500 1010.573373912 2759 D D 1843 + 96 [ftld] > 44,0 0 501 1010.581654276 2759 C D 1843 + 96 [0] > 44,0 0 502 1010.589936163 2759 C D 1859 + 80 [0] > 44,0 0 503 1010.598221556 2759 C D 1875 + 64 [0] > 44,0 0 504 1010.606505959 2759 C D 1891 + 48 [0] > 44,0 0 505 1010.614787227 2759 C D 1907 + 32 [0] > 44,0 0 506 1010.623061067 2759 C D 1923 + 16 [0] > > Do we want to pass nr_bytes into blk_add_trace_rq() from > __end_that_request_first()? Yep, that does indeed look like a bug! > It's also a bit suboptimal that 'blktrace /dev/ftla -o- | blkparse -i-' > stalls when it hits the first message packet, and then starts storing > requests to be sorted, never printing anything more until you hit ^C. > > I just removed the '&& bit->action != BLK_TN_MESSAGE' from line 2197 of > blkparse.c but that means the output isn't in the right order. Some kind > of partial sort might be nice, if we can do it -- wait for a pause or > some kind of marker in the stream, then sort and print what we have > batched, then continue waiting for new events... I'll take patches, it's a pretty tricky area... Live tracing really isn't that well supported, the only way to guarantee "perfect" traces is to do post-processing. -- Jens Axboe