From: Tejun Heo <htejun@gmail.com>
To: Mark Lord <liml@rtr.ca>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
jeff@garzik.org, linux-ide@vger.kernel.org, albertl@mail.com,
jens.axboe@oracle.com
Subject: Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands
Date: Fri, 30 Nov 2007 07:52:04 +0900 [thread overview]
Message-ID: <474F4294.9030203@gmail.com> (raw)
In-Reply-To: <474F0B11.7000205@rtr.ca>
Mark Lord wrote:
> I'm split on this one. For fast systems (typical notebook/desktop) it's
> almost a non-issue either way.
>
> But a lot of media boxes will be using this code, and they tend to have
> very low-power, slow-clockrate CPUs in the 200-800Mhz range, and so the
> real-time hit there (from PIO) will have a much more significant impact.
>
> Using DMA as much as possible on those slower platforms is definitely
> a plus towards avoiding non-jerky, skipped frames, or start-stoppy DVD
> recording.
>
> Now the most intensive commands are still DMA under the proposed scheme,
> so it's not those that one would be concerned with. But dropping to PIO
> even for a few uncommon commands will still peg a real-time hit or two
> on a slower media processor.
>
> So.. ????
One thing I don't understand about this argument is that PIO cycle time
is not determined by CPU power. It's bound by PCI and ATA bus speed.
If you put a faster CPU on the job, it just ends up wasting the same
amount of time burning up more CPU cycles or am I misjudging power of
those embedded CPUs?
--
tejun
next prev parent reply other threads:[~2007-11-29 22:52 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-29 14:33 [PATCHSET] libata: improve ATAPI data transfer handling, take #2 Tejun Heo
2007-11-29 14:33 ` [PATCH 01/14] libata: update atapi_eh_request_sense() such that lbam/lbah contains buffer size Tejun Heo
2007-11-29 15:51 ` Alan Cox
2007-12-04 19:27 ` Jeff Garzik
2007-12-05 0:47 ` Tejun Heo
2007-11-29 14:33 ` [PATCH 02/14] cdrom: add more GPCMD_* constants Tejun Heo
2007-11-29 14:33 ` [PATCH 03/14] libata: rename ATA_PROT_ATAPI_* to ATAPI_PROT_* Tejun Heo
2007-11-29 15:52 ` Alan Cox
2007-11-29 14:33 ` [PATCH 04/14] libata: add ATAPI_* cmd types and implement atapi_cmd_type() Tejun Heo
2007-11-29 14:33 ` [PATCH 05/14] libata: make ->data_xfer return the number of consumed bytes Tejun Heo
2007-11-29 15:55 ` Alan Cox
2007-11-29 16:06 ` Tejun Heo
2007-11-29 17:42 ` Alan Cox
2007-11-29 18:00 ` Tejun Heo
2007-11-29 18:24 ` Alan Cox
2007-11-29 18:57 ` Mark Lord
2007-11-29 19:37 ` Jeff Garzik
2007-11-29 19:36 ` Jeff Garzik
2007-11-29 21:22 ` Alan Cox
2007-12-04 19:30 ` Jeff Garzik
2007-12-05 0:49 ` Tejun Heo
2007-12-05 1:05 ` Jeff Garzik
2007-11-29 14:33 ` [PATCH 06/14] libata: improve ATAPI draining Tejun Heo
2007-11-29 15:59 ` Alan Cox
2007-11-29 16:09 ` Tejun Heo
2007-11-29 16:42 ` Tejun Heo
2007-11-29 17:40 ` Alan Cox
2007-11-29 18:11 ` Tejun Heo
2007-11-29 18:19 ` Alan Cox
2007-12-04 10:06 ` Albert Lee
2007-12-05 1:00 ` Tejun Heo
2007-11-29 14:33 ` [PATCH 07/14] libata: make atapi_request_sense() use sg Tejun Heo
2007-11-29 14:33 ` [PATCH 08/14] libata: kill non-sg DMA interface Tejun Heo
2007-11-29 16:00 ` Alan Cox
2007-12-04 19:31 ` Jeff Garzik
2007-12-05 1:02 ` Tejun Heo
2007-11-29 14:33 ` [PATCH 09/14] libata: change ATA_QCFLAG_DMAMAP semantics Tejun Heo
2007-11-29 14:33 ` [PATCH 10/14] libata: convert to chained sg Tejun Heo
2007-11-29 14:33 ` [PATCH 11/14] libata: add qc->dma_nbytes Tejun Heo
2007-11-29 16:02 ` Alan Cox
2007-12-04 19:33 ` Jeff Garzik
2007-12-05 1:02 ` Tejun Heo
2007-11-29 14:33 ` [PATCH 12/14] libata: implement ATAPI drain buffer Tejun Heo
2007-11-29 14:33 ` [PATCH 13/14] libata: implement ATAPI per-command-type DMA horkages Tejun Heo
2007-11-29 16:04 ` Alan Cox
2007-11-29 16:10 ` Tejun Heo
2007-11-29 14:33 ` [PATCH 14/14] libata: use PIO for misc ATAPI commands Tejun Heo
2007-11-29 16:05 ` Alan Cox
2007-11-29 16:14 ` Tejun Heo
2007-11-29 16:16 ` Tejun Heo
2007-11-29 18:55 ` Mark Lord
2007-11-29 22:52 ` Tejun Heo [this message]
2007-11-30 1:03 ` Mark Lord
2007-11-30 1:34 ` Tejun Heo
2007-11-30 4:19 ` Mark Lord
2007-11-30 13:40 ` Alan Cox
2007-11-30 13:59 ` Tejun Heo
2007-11-30 14:12 ` Jeff Garzik
2007-11-30 15:36 ` Alan Cox
2007-11-30 13:09 ` Alan Cox
2007-11-29 17:38 ` Alan Cox
2007-12-04 19:34 ` Jeff Garzik
2007-12-05 1:14 ` Tejun Heo
2007-12-05 12:47 ` Alan Cox
2007-12-05 13:03 ` Tejun Heo
2007-12-05 14:01 ` Alan Cox
2007-12-05 14:22 ` Tejun Heo
2007-12-05 14:46 ` Alan Cox
2007-12-05 15:13 ` Tejun Heo
2007-12-05 18:52 ` Jeff Garzik
2007-12-06 11:03 ` Petr Vandrovec
2007-12-06 11:10 ` Tejun Heo
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=474F4294.9030203@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
/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.