On 06/30/2016 08:49 AM, Vincent Fu wrote:
Jens, I have been working on a patch to give fio the ability to terminate a job when steady state is attained. I have a crude implementation that is working at https://bitbucket.org/vincentfu/fio/commits/all but I'm hoping to receive some feedback on its design. Currently, the feature works via helper_thread_main(). It collects data in a ring buffer for a specified duration and carries out the termination test when the ring buffer is full. If the test passes, the job terminates. If the test fails, the job continues, the oldest data point in the buffer is dropped, a new data point is added, and the termination test is carried out again. The cycle repeats until the job terminates because steady state was attained or for other reasons.
Vincent, where are we at on this? Would be nice to get this included. A few comments:
- The global 'steadystate' bool. Seems like this should be a per-job thing, and not global. For a specific group of threads, whether we are in steady state or not should be checked for those td's.
- Should still work with ramptime. If we're in ramp time, no checking. Start steady state checking once we are out of ramp time.
- Would be nice if the SS output was there for non-json. At least something for the normal output, I think we can safely ignore the terse/csv in this regard.
- Should struct steady_state just be embedded in the thread_stat? It needs to be transmitted across the wire for client/server. So either you need to split it in two, or you need to embed it and sanitize it for on-the-wire transmission. You could keep the td->ss, and have a version that we export and embed that in thread_stat? If you do that, then have a steady_state_bla that's embedded in both struct steady_state and struct thread_stat.
Rest of the comments would be around cleanup, lots of little extra spaces here and there. But I can script sanitize that, so didn't want to address that in here.
-- 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
