Hi, I tried the flow feature on a two jobs workload as a simple test but when using fio in VM as load generator, fio use 100% of the CPU in each VM. Is that expected? As a result, there was basically no workload read/write to the disks. I may have misconfigured something but I did use it as in the butterfly seek pattern example replacing the jobs by one for read and a second one for write. I put flow=7 in first job and flow=3 in the second job to get 70%/30%. As it was using all the resources, I didn't push it more and try it on physical servers as that's not how we want to operate when doing load simulation. I don't have this issue when using fio without flow in those same VM. Let me know if you have suggestion around flow with VM, I'm willing to test it further if you think it should work without overloading the CPU in such a setup. Thank you. Etienne -----Message d'origine----- De : Sitsofe Wheeler <sitsofe@xxxxxxxxx> Envoyé : October 18, 2018 12:19 AM À : Elliott, Robert (Persistent Memory) <elliott@xxxxxxx> Cc : efortin@xxxxxxxxxxxxxxxx; fio <fio@xxxxxxxxxxxxxxx>; Jens Axboe <axboe@xxxxxxxxx> Objet : Re: FIO 3.11 On Wed, 17 Oct 2018 at 22:45, Elliott, Robert (Persistent Memory) <elliott@xxxxxxx> wrote: > > > These will make each thread implement your desired mix: > > rwmixread=int [...] > rwmixwrite=int [...] > percentage_random=int[,int][,int] [...] Another (but more overlooked) option for forcing different jobs into lockstep with each other is the flow parameter - https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-flow but it tends to be easiest to reason about when there are just two jobs. > > Threads running sequential accesses can easily benefit from cache hits > from each other, if there is any caching or prefetching done by the > involved drivers or devices. One thread takes the lead and suffers > delays, while the others benefit from its work and stay close behind. They can take turns, but tend to stay clustered together. This can distort results. > Random accesses avoid that problem, provided the capacity is much larger than any caches. -- Sitsofe | https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fsucs.org%2F~sits%2F&data=02%7C01%7C%7C2de2c820b1974b8382a108d634b0ef20%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636754331855075106&sdata=20GnbqizCda6HeFLBoGmyHwLjtd%2BbBGeVrTkgua0vgE%3D&reserved=0
