On 02/01/2012 02:40 AM, Steven Lang wrote: > 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. That's not always the case, if you are using async verifies you can have multiple threads/CPUs looking at the same buffers. > Do you happen to remember what sort of case was buggy and causing this > to fail? Let me see if I can find the thread... OK, here it is: http://www.spinics.net/lists/fio/msg00538.html I think the issue just dropped off the debug todo. I'd appreciate your input :-) -- Jens Axboe -- 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
