Re: [PATCH 2/2] libata: turn off NCQ if queue depth is adjusted to 1

[Jens Axboe <jens.axboe@oracle.com>]

On Sat, Dec 16 2006, Jeff Garzik wrote:
> Ric Wheeler wrote:
> >Just thinking out loud, but it would be really helpful to get drive 
> >vendor's a basic set of tests for Linux systems -  error handling, 
> >performance, SMART features, etc - that would run natively on linux.
> >We would need to get something really easy to deploy, like a live CD 
> >image with the test suite that could be booted on a pc, to get into an 
> >environment that is used to booting DOS based floppies...
> 
> Strongly agreed.
> 
> I know some people use DOS-based environments; I would prefer the 
> following test environment:
> 
> Equip systems with NICs that can do wake-on-lan and PXE.  To initiate 
> testing of a system, perform a PXE boot, which downloads a 
> custom-compiled kernel and initrd over the net.  The kernel boots, sets 
> up a test environment in either ramfs or nfs (or a combination thereof), 
> and runs a "do everything" script which starts the tests specified by 
> the network admin.
> 
> The tests performed should be in three classes:  (1) data and non-data 
> tests performed over a "direct submit" interface like SG_IO, (2) data 
> tests performed by directly accessing the block device, and (3) data 
> tests performed by accessing data through a common filesystem [ext3 or 
> whatever is popular].
> 
> It is already trivial to write tests for #2 and #3.  Tests in class #1 
> may require some thought and complexity, such as using multiple threads, 
> to achieve maximal use of command queueing features.  I'm not aware of 
> any userspace interface that allows fine-grained control of TCQ (Jens 
> correct me here), or even an interface that does not require multiple 
> threads to submit multiple tasks simultaneously.

fio can do all of that, it supports a variety of io engines that allow
you to control the queue depth. So for SG_IO, you can obviously only do
depth of 1 as it's a sync interface, but the fio sg io engine also
supports the async /dev/sg (or bsg) interface that allows you to do
queueing.

Using fio it's quite simple to stress test the various interfaces. From
the io scheduler POV, it's also quite interesting to mix eg normal block
device access with SG_IO, to test that as well.

-- 
Jens Axboe