In comparing the performance between older versions of fio and newer
versions, I noticed right away that pattern writes were slower in fio
2.0.1. Running perf showed that most of the time spent in fio was in
fill_pattern (Over 50% of the CPU time), which was not the case in the
past.
This seems like it is worth it to have around, however a year ago it
was commented out with the following commit log:
Author: Jens Axboe <jaxboe@xxxxxxxxxxxx> 2011-01-14 06:32:30
Committer: Jens Axboe <jaxboe@xxxxxxxxxxxx> 2011-01-14 06:32:30
Parent: 9a793c2f91a47df348237f1a9b778253ca87ec2e (Fix race in exit of
eta/util thread)
Child: 69204d6e8830464bc98fcc28ca91412d6d360775 (Eta/disk thread uses
more than the minimum stack)
Branches: continue_on_error_type_2, master, remotes/origin/master,
remotes/origin/stable-1.x
Follows: fio-1.50-rc2
Precedes: fio-1.50-rc3
Comment out ->buf_filled_len in pattern fill
It's buggy, needs to be debugged. Disable for now. It can cause
verify failures.
Signed-off-by: Jens Axboe <jaxboe@xxxxxxxxxxxx>
And in the code the comments say "We need to ensure that the pattern
stores are seen before the fill length store, or we could observe
headers that aren't valid to the extent notified by the fill length".
However I'm having trouble imaging a case when that will happen, given
that buffers are filled and consumed within the context of a single
thread.
Do you happen to remember what sort of case was buggy and causing this to fail?
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
