From: Jens Axboe <axboe@kernel.dk>
To: Andrey Kuzmin <andrey.v.kuzmin@gmail.com>
Cc: Gwendal Grignou <gwendal@chromium.org>,
"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: [PATCH] verify: Fix latency log for verify commands.
Date: Mon, 09 Feb 2015 08:27:40 -0700 [thread overview]
Message-ID: <54D8D1EC.5080008@kernel.dk> (raw)
In-Reply-To: <CANvN+e=KcRLWA3XsBtkgmpcSZcAoa7VdyD5wT-_mCJbFH_c+2w@mail.gmail.com>
On 02/09/2015 08:25 AM, Andrey Kuzmin wrote:
> On Mon, Feb 9, 2015 at 6:17 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 02/09/2015 02:39 AM, Andrey Kuzmin wrote:
>>>
>>> On Mon, Feb 9, 2015 at 6:53 AM, Gwendal Grignou <gwendal@chromium.org>
>>> wrote:
>>>>
>>>> When commands when requeued for the verify operation,
>>>> their start time was not reset, resulting in bogus latency graphs.
>>>
>>>
>>> Does it really make sense to account for the verification pass in the
>>> latency profile?
>>
>>
>> Why not? If you are doing a full write then verification, you get a full set
>> of separate read and write latencies.
>
> I'd rather get them on a per-pass basis. Imagine an r/w workload being
> done with verification pass (just to be on the safe side): I'd rather
> keep read-only verification pass latencies separate from the primary
> workload latency profile. YMMW :).
Sure, if it's a mixed read/write workload and you verify after the fact,
then it could be handy to have the two "different" kinds of reads
separate. But that's really orthogonal to the issue being fixed by
Gwendals patch...
--
Jens Axboe
next prev parent reply other threads:[~2015-02-09 15:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 3:53 [PATCH] verify: Fix latency log for verify commands Gwendal Grignou
2015-02-09 9:39 ` Andrey Kuzmin
2015-02-09 15:17 ` Jens Axboe
2015-02-09 15:25 ` Andrey Kuzmin
2015-02-09 15:27 ` Jens Axboe [this message]
2015-02-09 15:59 ` Andrey Kuzmin
2015-02-09 15:16 ` Jens Axboe
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=54D8D1EC.5080008@kernel.dk \
--to=axboe@kernel.dk \
--cc=andrey.v.kuzmin@gmail.com \
--cc=fio@vger.kernel.org \
--cc=gwendal@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox