linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Read Prefetch, Post Write on IDE chipsets
@ 2007-09-02 12:51 Matt Sealey
  2007-09-02 14:00 ` Alan Cox
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Matt Sealey @ 2007-09-02 12:51 UTC (permalink / raw)
  To: linux-ide

Hi guys,

Does anyone have any decent information on the purpose, performance potential
or perhaps quirks of the "read prefetch" and "post write" buffer features on
some IDE chipsets?

It doesn't look like any standard but at least is included in quite a few
of the libata drivers, and a lot of x86 BIOS control has toggles to try and
turn it on or off.

But, what is it? I've never seen any documentation but which register to use
to toggle it.. no vendor recommendations to turn it on, it seems like a rather
secret feature..?

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Read Prefetch, Post Write on IDE chipsets
  2007-09-02 12:51 Read Prefetch, Post Write on IDE chipsets Matt Sealey
@ 2007-09-02 14:00 ` Alan Cox
  2007-09-02 14:04   ` Matt Sealey
  2007-09-02 14:07 ` Sergei Shtylyov
  2007-09-02 14:12 ` Sergei Shtylyov
  2 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2007-09-02 14:00 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linux-ide

On Sun, 02 Sep 2007 13:51:43 +0100
Matt Sealey <matt@genesi-usa.com> wrote:

> Hi guys,
> 
> Does anyone have any decent information on the purpose, performance potential
> or perhaps quirks of the "read prefetch" and "post write" buffer features on
> some IDE chipsets?
> 
> It doesn't look like any standard but at least is included in quite a few
> of the libata drivers, and a lot of x86 BIOS control has toggles to try and
> turn it on or off.
> 
> But, what is it? I've never seen any documentation but which register to use
> to toggle it.. no vendor recommendations to turn it on, it seems like a rather
> secret feature..?

Chipset specific. Some public documentation discusses it for certain
chips (eg the Intel ATA tuning guidelines). For others you may need the
BIOS vendor manual or similar.

Alan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Read Prefetch, Post Write on IDE chipsets
  2007-09-02 14:00 ` Alan Cox
@ 2007-09-02 14:04   ` Matt Sealey
  0 siblings, 0 replies; 6+ messages in thread
From: Matt Sealey @ 2007-09-02 14:04 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-ide

Alan Cox wrote:
> On Sun, 02 Sep 2007 13:51:43 +0100
> Matt Sealey <matt@genesi-usa.com> wrote:
> 
>> But, what is it? I've never seen any documentation but which register to use
>> to toggle it.. no vendor recommendations to turn it on, it seems like a rather
>> secret feature..?
> 
> Chipset specific. Some public documentation discusses it for certain
> chips (eg the Intel ATA tuning guidelines). For others you may need the
> BIOS vendor manual or similar.

All I see is.. that if you want to turn it on, you must make sure of a few things.

There is no discussion on what it DOES, I assume it simply buffers a little more
somewhere (somehow?) inside the chipset, for the purpose of allowing more
streamlined PIO access. But it has some awesome limitations..

Is it even relevant anymore? Does anyone even notice if these features are turned off?

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Read Prefetch, Post Write on IDE chipsets
  2007-09-02 12:51 Read Prefetch, Post Write on IDE chipsets Matt Sealey
  2007-09-02 14:00 ` Alan Cox
@ 2007-09-02 14:07 ` Sergei Shtylyov
  2007-09-02 14:12 ` Sergei Shtylyov
  2 siblings, 0 replies; 6+ messages in thread
From: Sergei Shtylyov @ 2007-09-02 14:07 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linux-ide

Hello.

Matt Sealey wrote:

> Does anyone have any decent information on the purpose,

    Prefetch allows the controller to keep reading data until it fills it's 
(usually 512 byte sector but may be programmable size on some devices to 
accomodate ATAPI) not waiting for PCI I/O read cycles -- which are than 
satisfied from that buffer (if it's not empty). So, this effectively decoples 
PCI and IDE transactions.

> performance potential
> or perhaps quirks of the "read prefetch" and "post write" buffer 
> features on some IDE chipsets?

    The quirks are quite well known: non-data reads get into the prefetch 
buffer, sometimes even reads from the mate channel which causes the wrong 
sector data to be read and buffer left in non-empty state, thus causing wrong 
reads afterwards, if the measures are not taken (like the buffer reset).

> It doesn't look like any standard but at least is included in quite a few
> of the libata drivers,

   It may be considered a "de facto" standard.

> and a lot of x86 BIOS control has toggles to try and turn it on or off.

   Yeah, for ATAPI devices it's usually turned off (unless meybe for the 
commands known to return a power of 2 bytes of data, like 2KiB).

> But, what is it? I've never seen any documentation but which register to 
> use
> to toggle it..

    I can advice reading Intel's manual, 29860004.pdf, or the datasheets for 
the concrete chipset...

> no vendor recommendations to turn it on, it seems like a rather
> secret feature..?

    Just misdocoumeted and/or buggy sometimes.  It's generally a good idea to 
turn it off for ATAPI devices, and on for normal disks (unless there's a known 
bug in its implementation).

MBR, Sergei

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Read Prefetch, Post Write on IDE chipsets
  2007-09-02 12:51 Read Prefetch, Post Write on IDE chipsets Matt Sealey
  2007-09-02 14:00 ` Alan Cox
  2007-09-02 14:07 ` Sergei Shtylyov
@ 2007-09-02 14:12 ` Sergei Shtylyov
  2007-09-02 14:23   ` Sergei Shtylyov
  2 siblings, 1 reply; 6+ messages in thread
From: Sergei Shtylyov @ 2007-09-02 14:12 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linux-ide

Matt Sealey wrote:

> Does anyone have any decent information on the purpose, performance 
> potential
> or perhaps quirks of the "read prefetch" and "post write" buffer 
> features on
> some IDE chipsets?

    Oh, I've forgotten to reply about posting. :-)
There's a (little) wrtie post buffer in the IDE contoroller where it puts the 
data from the PCI and GNTs the PCI transfer.  The data later get output to the 
IDE bus when the IDE timings are met, so the slow IDE transfers (which usually 
need to wait for active/recovery time) doesn't hog the PCI too.

MBR, Sergei

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Read Prefetch, Post Write on IDE chipsets
  2007-09-02 14:12 ` Sergei Shtylyov
@ 2007-09-02 14:23   ` Sergei Shtylyov
  0 siblings, 0 replies; 6+ messages in thread
From: Sergei Shtylyov @ 2007-09-02 14:23 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: Matt Sealey, linux-ide

Hello, I wrote:

>> Does anyone have any decent information on the purpose, performance 
>> potential
>> or perhaps quirks of the "read prefetch" and "post write" buffer 
>> features on
>> some IDE chipsets?

>    Oh, I've forgotten to reply about posting. :-)
> There's a (little) wrtie post buffer in the IDE contoroller where it 
> puts the data from the PCI and GNTs the PCI transfer.  The data later 

    Perhaps I've used GNT incorrectly: it seems to be a signal between a 
master PCI device and PCI arbiter.
    So, the write buffer just helps to teminate PCI write(s) earlier than the 
data arrive to the drive.

MBR, Sergei

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-09-02 14:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-02 12:51 Read Prefetch, Post Write on IDE chipsets Matt Sealey
2007-09-02 14:00 ` Alan Cox
2007-09-02 14:04   ` Matt Sealey
2007-09-02 14:07 ` Sergei Shtylyov
2007-09-02 14:12 ` Sergei Shtylyov
2007-09-02 14:23   ` 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).