Re: [PATCH 0/9] introduce the log_issue_time option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Aug 29, 2024 / 09:59, Damien Le Moal wrote:
> On 8/29/24 02:06, Jens Axboe wrote:
> > On 8/27/24 1:08 AM, Shin'ichiro Kawasaki wrote:
> >> When write_lat_log option is set, fio outputs the 'clat' completion
> >> latency log file. This clat log can be used to analyze IO latency. This
> >> file can also be considered as an IO trace file as each IO entry can
> >> fully describe an IO when the --log_offset and --log_prio options are
> >> also used. However, using the clat log file as an IO trace is inaccurate
> >> because the time field of each entry uses millisecond units, which is
> >> too coarse for fast IOs (e.g. when using SSDs). This series proposes the
> >> new option 'log_issue_time' to address the inaccuracy problem. When this
> >> option is set, fio adds another field to the log file entries to log an
> >> IO issuing time in nanoseconds.
> >>
> >> The first four patches in the series clean up the current code as
> >> preparation. The 5th patch introduces the 'log_issue_time' option. The
> >> following two patches document the new option. The last two patches add
> >> two test cases to check the log file format.
> > 
> > In general this looks fine, and I think it's a useful feature. However,
> > should we have an option to make the generic time in the log entry be
> > in nsec as well?
> 
> I am not sure if it is that useful given that the entry time field does not
> directly correspond to any I/O time.

I noted it in the commit message of the 5th patch, but did not in this cover
letter (sorry). Quote from the 5th patch commit message:

    However, using the clat log file as an IO trace is inaccuate due to two
    reasons. Firstly, the time field of each entry uses millisecond units,
    which is too coarse for fast IOs (e.g. when using SSDs). Secondly, the
    time field value is recorded not at command completion, but at log
    sample recording. The time field value is slightly different from the IO
    completion time. It can be used only as an approximated completion time.

That's why we propose to add the new field for the command issue time, instead
of the log entry in nsec.

> But to be consistent with the other time
> fields, I may be good to add this option. That is easy to do.
> 
> -- 
> Damien Le Moal
> Western Digital Research
> 




[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux