From: Jeff Garzik <jgarzik@pobox.com>
To: Ric Wheeler <ric@emc.com>
Cc: Tejun Heo <htejun@gmail.com>, Jens Axboe <axboe@kernel.dk>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ide@vger.kernel.org
Subject: Re: [PATCH 2/2] libata: turn off NCQ if queue depth is adjusted to 1
Date: Sat, 16 Dec 2006 12:19:35 -0500 [thread overview]
Message-ID: <45842AA7.5060204@pobox.com> (raw)
In-Reply-To: <451FBAFC.4040001@emc.com>
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.
Jeff
next prev parent reply other threads:[~2006-12-16 17:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-30 10:44 [PATCH 1/2] libata: cosmetic changes to constants Tejun Heo
2006-09-30 10:45 ` [PATCH 2/2] libata: turn off NCQ if queue depth is adjusted to 1 Tejun Heo
2006-09-30 18:04 ` Jens Axboe
2006-09-30 20:51 ` Alan Cox
2006-09-30 20:26 ` Jens Axboe
2006-10-01 0:17 ` Ric Wheeler
2006-10-01 0:29 ` Tejun Heo
2006-10-01 0:52 ` Ric Wheeler
2006-10-01 12:56 ` Ric Wheeler
2006-12-16 17:19 ` Jeff Garzik [this message]
2006-12-18 10:04 ` Jens Axboe
2006-10-01 19:55 ` Jens Axboe
2006-10-04 13:37 ` saeed bishara
2006-10-04 13:37 ` Jens Axboe
2006-10-05 9:08 ` Jens Axboe
2006-09-30 11:39 ` [PATCH 1/2] libata: cosmetic changes to constants Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45842AA7.5060204@pobox.com \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@kernel.dk \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=ric@emc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.