Flexible I/O Tester development
 help / color / mirror / Atom feed
* IO scheduler
@ 2013-10-10 17:08 Brian L.
  2013-10-10 20:55 ` David Nellans
  0 siblings, 1 reply; 4+ messages in thread
From: Brian L. @ 2013-10-10 17:08 UTC (permalink / raw)
  To: fio@vger.kernel.org

Hi there,

I was wondering if you guys use NOOP IO scheduler when you are running fio?

I use the CFQ IO scheduler but I do put the OS into init 1 and run fio
process one at a time so that I can get accurate readings.

I was wondering what are people practice and experience in the real world.

Thanks,
Brian L.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IO scheduler
  2013-10-10 17:08 IO scheduler Brian L.
@ 2013-10-10 20:55 ` David Nellans
  2013-10-10 21:00   ` Erwan Velu
  0 siblings, 1 reply; 4+ messages in thread
From: David Nellans @ 2013-10-10 20:55 UTC (permalink / raw)
  To: Brian L., fio@vger.kernel.org

On 10/10/2013 12:08 PM, Brian L. wrote:
> Hi there,
>
> I was wondering if you guys use NOOP IO scheduler when you are running fio?
>
> I use the CFQ IO scheduler but I do put the OS into init 1 and run fio
> process one at a time so that I can get accurate readings.
>
> I was wondering what are people practice and experience in the real world.
>
> Thanks,
> Brian L.

Some flash device drivers specifically (Fusion-io does this) use the 
noop scheduler to reduce latency and variance that can be introduced 
when using other schedulers.  Using the no-op scheduler is a reasonable 
thing to do for all drives to make apples to apples, but if a driver 
specifically overrides it to something else, probably worth sticking 
with their settings.

init 1 is overkill.  In a previous life doing a lot of measuring of 
flash - I found that simply making sure the machine was "idle" you could 
get easily get repeatability within 1% for devices doing several hundred 
thousand IOPS, even those with on-load architectures that were sensitive 
to CPU usage.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IO scheduler
  2013-10-10 20:55 ` David Nellans
@ 2013-10-10 21:00   ` Erwan Velu
  2013-10-10 21:18     ` David Nellans
  0 siblings, 1 reply; 4+ messages in thread
From: Erwan Velu @ 2013-10-10 21:00 UTC (permalink / raw)
  To: David Nellans; +Cc: Brian L., fio@vger.kernel.org

On 10/10/2013 22:55, David Nellans wrote:
> [...]
> init 1 is overkill.  In a previous life doing a lot of measuring of 
> flash - I found that simply making sure the machine was "idle" you 
> could get easily get repeatability within 1% for devices doing several 
> hundred thousand IOPS, even those with on-load architectures that were 
> sensitive to CPU usage.
On my side, I've been creating a specific ramfs that does the fio 
testing I want. This way I'm sure that nothing else is running on my 
system (like daemons or gui stuff).

That's a little bit extreme but it insures the same OS & environment to 
be used over & over making all my tests much more comparable over time.

My 2 cents,

Erwan,

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IO scheduler
  2013-10-10 21:00   ` Erwan Velu
@ 2013-10-10 21:18     ` David Nellans
  0 siblings, 0 replies; 4+ messages in thread
From: David Nellans @ 2013-10-10 21:18 UTC (permalink / raw)
  To: Erwan Velu; +Cc: Brian L., fio@vger.kernel.org


> That's a little bit extreme but it insures the same OS & environment to
> be used over & over making all my tests much more comparable over time.
>
Thats a really good point - I guess I should also be a little more 
specific about how we achieved tight reproducibility.

We used dedicated machines with identical components, a fixed point 
within an OS distribution, a known bios revision/settings, and disabled 
any/all frequency/power scaling.  So while we ran the machines without 
any special tricks, the machine configurations and OS were very 
extremely locked down and identical except for a hostname.

Anytime we changed anything within the cluster configuration we 
quantified the change before rolling it out cluster wide since on more 
than one occasion we discovered even things like bios revisions would 
substantially affect PCIe based testing.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-10-10 21:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-10 17:08 IO scheduler Brian L.
2013-10-10 20:55 ` David Nellans
2013-10-10 21:00   ` Erwan Velu
2013-10-10 21:18     ` David Nellans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox