Why so much PIO for r/w accesses ?

All of lore.kernel.org
 help / color / mirror / Atom feed

From: Mark Lord <kernel@teksavvy.com>
To: IDE/ATA development list <linux-ide@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>, Tejun Heo <htejun@gmail.com>
Subject: Why so much PIO for r/w accesses ?
Date: Sun, 21 Nov 2010 18:35:06 -0500	[thread overview]
Message-ID: <4CE9ACAA.9060203@teksavvy.com> (raw)

While working on something unrelated today,
I instrumented ata_sff_data_xfer32() to generate a printk() on each invocation.

Imagine then my complete surprise to see that print() being invoked very frequently
after rebooting with the modified kernel.

ata_sff_data_xfer32() is for PIO read/writes.. something that I don't expect to see.

This is an ata_piix system, with a pure SATA SSD.
Why are we using PIO so much?
Or am I simply misunderstanding something basic here.. ?

Confused.

ata_sff_data_xfer32: buf=f68015fc:512 (write)
ata1.00: ATA-8: OCZ-VERTEX, 1.6, max UDMA/133
ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 0/32)
ata_sff_data_xfer32: buf=f6801f80:512 (write)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      OCZ-VERTEX       1.6  PQ: 0 ANSI: 5
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA
  sda:
  sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
ata_sff_data_xfer32: buf=f68055fc:512 (write)
ata2.00: ATAPI: SlimtypeDVD A  DS8A1P, CX16, max UDMA/33
ata_sff_data_xfer32: buf=f6805f80:512 (write)
ata2.00: configured for UDMA/33
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f7088e00:36 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
scsi 1:0:0:0: CD-ROM            Slimtype DVD A  DS8A1P    CX16 PQ: 0 ANSI: 5
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f73b1580:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f73b1580:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f73f1900:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
...

ata_sff_data_xfer32: buf=f6601000:512 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f648fe00:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f65b5000:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f6568900:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f6891d80:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f65abf00:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f6918780:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f651a000:8 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=fffb1bac:36 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f651a000:348 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f65ab680:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f68d2400:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f65b5980:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f6aa4200:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f6b8b380:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f69c2600:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
ata_sff_data_xfer32: buf=f68053a8:12 (read)
ata_sff_data_xfer32: buf=f65b8980:18 (write)
ata_sff_data_xfer32: buf=f68040c4:12 (read)
...

next             reply	other threads:[~2010-11-21 23:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-21 23:35 Mark Lord [this message]
2010-11-21 23:39 ` Why so much PIO for r/w accesses ? Mark Lord
2010-11-22 11:35 ` Sergei Shtylyov

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=4CE9ACAA.9060203@teksavvy.com \
    --to=kernel@teksavvy.com \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --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.