* Why so much PIO for r/w accesses ?
@ 2010-11-21 23:35 Mark Lord
2010-11-21 23:39 ` Mark Lord
2010-11-22 11:35 ` Sergei Shtylyov
0 siblings, 2 replies; 3+ messages in thread
From: Mark Lord @ 2010-11-21 23:35 UTC (permalink / raw)
To: IDE/ATA development list, Jeff Garzik, Tejun Heo
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)
...
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why so much PIO for r/w accesses ?
2010-11-21 23:35 Why so much PIO for r/w accesses ? Mark Lord
@ 2010-11-21 23:39 ` Mark Lord
2010-11-22 11:35 ` Sergei Shtylyov
1 sibling, 0 replies; 3+ messages in thread
From: Mark Lord @ 2010-11-21 23:39 UTC (permalink / raw)
To: IDE/ATA development list, Jeff Garzik, Tejun Heo
On 10-11-21 06:35 PM, Mark Lord wrote:
> 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.
Definitely just me being confused. :)
I changed the printk() into an ata_dev_printk(), and discovered that
all of those reads/writes are targeting the DVD-RW drive, not the SSD.
So this is simply hald or something similar polling for disc-insertion,
and PIO is used (as always) for the PACKET command transfer.
Duh. :)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why so much PIO for r/w accesses ?
2010-11-21 23:35 Why so much PIO for r/w accesses ? Mark Lord
2010-11-21 23:39 ` Mark Lord
@ 2010-11-22 11:35 ` Sergei Shtylyov
1 sibling, 0 replies; 3+ messages in thread
From: Sergei Shtylyov @ 2010-11-22 11:35 UTC (permalink / raw)
To: Mark Lord; +Cc: IDE/ATA development list, Jeff Garzik, Tejun Heo
Hello.
On 22-11-2010 2:35, Mark Lord wrote:
> 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.
Most PIO I/O you saw points to an ATAPI device...
> 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)
I think you have your (read)/(write) backwars. 12 bytes is the typical CDB
length -- and CDB is written, not read. 36 bytes seems to be INQUIRY data
length -- which is read, not written. 512 bytes then stand for IDENTIFY
[PACKET] DEVICE data.
> 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)
This seems to be REQUEST SENSE command and (perhaps) TEST UNIT READY
preceding it...
> ...
You're seeing so many PIO transfers because libata doesn't use DMA with
ATAPI transfers which aren't divisible by sector size (this is a hardware
limitation on many chips).
WBR, Sergei
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-11-22 11:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-21 23:35 Why so much PIO for r/w accesses ? Mark Lord
2010-11-21 23:39 ` Mark Lord
2010-11-22 11:35 ` Sergei Shtylyov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).