On 2022-05-19 13:35:02, Vincent Fu wrote: >> -----Original Message----- >> From: Antoine Beaupré [mailto:anarcat@xxxxxxxxxxxxxx] [...] >> Speaking of which, it's not clear to me if I need to add stonewall to >> each job or if I can just add it to the top-level global options and be >> done with it... > > The stonewall option is needed only in the global section and will apply > to all of the jobs. That's great to hear, thanks. That makes total sense. It can still be applied only to a single job if I want too, right? >> So maybe the bug is *just* 1 and 2: (1) the timestamps in the final >> report are incorrect, and (2) processes are all started at once (and 1 >> may be related to 2!) > > The timestamp is actually the time at which the summary output was generated, > not the time the job started or stopped. > > https://github.com/axboe/fio/blob/fio-3.30/stat.c#L1161 Aaah... so that's why I was confused. Could this be changed? It looks like neither the group_run_stats or the thread_stat structs have the start timestamps, although thread_stat has the runtime... Maybe it could be extended so that the display is a little less confusing? Or maybe I'm the only one confused by this? > All of the processes are created when fio starts up but they do not start issuing IO > until it is their turn. Couldn't this affect metrics, especially on low-end systems with lots of jobs? I would think that some processes could end up being swapped in and out... If a process is stonewalled, I would have assumed it only *starts* after the stonewall. -- Antoine Beaupré torproject.org system administration
