Skip to contentSkip to conversation

rate option doesnt work with libaio engine

DISCUSSION Radha Ramachandran 2 participants 2 messages Dec 9, 2009

lore
Share & tools
lore
#0 lore raw

Hi,
The rate option currently doesnt work when used with libaio engine. The math currently, calculates the time t2 (when the I/O completed) - t1 (when the io_u unit was created) as the time it takes for the I/O and the bandwidth for the rate calculation is calculated from that. This math will work correctly for sync engine as there is only one io in progress at a time, but for libaio engine, when there are multiple I/Os queued, the same time (as in from t1 to t2) could be attributed to other I/Os as well so the actual bandwidth is actually higher. I have a patch, but this is more brute force where I take the total bytes read/written divided by the time since I/Os started to calculate the bandwidth and decide on the time that needs to be spent sleeping (if any).This is a little more heavy weight than the previous math. I think there are probably simpler/cleaner solutions than this but this is the current patch I have for it.
Thanks
-radha

#1 lore raw
Quoted 7 lines · Radha Ramachandran

Hi,
The rate option currently doesnt work when used with libaio engine. The math currently, calculates the time t2 (when the I/O completed) - t1 (when the io_u unit was created) as the time it takes for the I/O and the bandwidth for the rate calculation is calculated from that. This math will work correctly for sync engine as there is only one io in progress at a time, but for libaio engine, when there are multiple

Quoted 8 lines

I/Os queued, the same time (as in from t1 to t2) could be attributed to other I/Os as well so the actual bandwidth is actually higher. I have a patch, but this is more brute force where I take the total bytes read/written divided by the time since I/Os started to calculate the bandwidth and decide on the time that needs to be spent sleeping (if any).This is a little more heavy weight than the previous math. I think there are probably simpler/cleaner solutions than this but this is the current patch I have for it.

Good analysis, yeah it definitely is broken currently, it basically turns out to be rate*iodepth. Which is broken, of course. I have applied your patch in lieu of a better idea. Don't worry about the bit of extra math. I try to keep fio lean (and it is), the biggest problem is usually the huge amounts of gettimeofday() calls when you do high iops counts.

Signature · 1 line
Jens Axboe