Re: High-performance IO

Any well implemented PCI DMA these days will both support over 4GB
addressing and scatter gather so the pages do not have to be contiguous.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



"Piotr Wyderski" <wyderski@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:eag2h9$pt8$1@xxxxxxxxxxxxxxxxxxxxx
Hi Anton,

First of all, memory does not have to be physically contigious - the
only thing you need is to make it resident and locked

Surely, but discontinuities limit the length of the DMA transfers.
If the length of a contiguous memory block is equal to the size
of a virtual memory page, the DMA transfer length will be at
most 4KiB too -- not a very impressive value... The other limiting
factor if the cluster size, so the buffer doesn't have to be contiguous
that much.

But I don't know whether the disk drivers are supposed to support 64-bit
(36, in fact) physical addressing.

Drivers are not concerned about things like that - after all, they deal
only with linear addresses.

But eventually they must issue a DMA transfer request (does
anyone stil use PIO?) and they work only with physical memory.
That rises two questions:

a) what is the upper limit of a DMA disk transfer, how is it
computed on a Windows XP-based machine and by whom?

b) is the underlying hardware able to access physical memory
above 4GiB? There may still be some 32-bit oddities etc.

I know that AWE can give the programmer a way to use
huge memory, but the problem is whether a physical memory
block from the AWE area is guaranteed to be reachable via
PCI etc. If one completes a data block in AWE and issue an IO request, it
would not be desirable to receive an error
code like E_INVALID_PHYSICAL_MEMORY_RANGE
or something. I ask, because the following excerpt from MSDN
is the seed of doubt:

"A similar restriction is that AWE window address ranges and memory
pools cannot be used as data buffers for graphics or video calls."

And since AGP and PCI buses are being implemented in a quite
similar way, this remark naturally scales up the problem to a question
"does this restriction apply to disks too?"

Unfortunately, there is not much information available at the
level of detail I would like to know... :-(

The only problem is that AWE requires SeLockMemory privilege

I believe it will not be a big problem, especially that it is just an
alternative control flow path -- without that privilege my application
will simply use the old good VirtualAlloc-based way. But indeed,
the temptation to use AWE is very strong... :-)

Best regards
Piotr Wyderski

PS. The current, improved implementation is damn fast
and no longer is the performance limiting factor. :-)



.

Relevant Pages

  • Re: A simple question about DMA, please help me.
    ... held by the DMA controller and the CPU is set idle until this transfer ... memory to fetch instructions while the DMA transfer is continuing. ... The PCI bus changed that -- it eliminated the separate lines for each ...
    (comp.lang.asm.x86)
  • Re: Trying to DMA data from PCI bus to IDE
    ... >to handle DMA transfers across the PCI bus to the rest of the PC104 ... >memory, and then use the regular Linux functions to write it to the ...
    (comp.os.linux.development.system)
  • Re: PCI DMA Address
    ... I don't think ioremap is what you want here. ... memory region on the card itself. ... Subject: PCI DMA Address ...
    (Linux-Kernel)
  • [PATCH] Documentation: mv DMA-* to separate DMA/ subdirectory
    ... -This document describes the DMA API. ... -corresponding pci_ API. ... -for supporting non-consistent memory machines. ... -Many drivers need lots of small dma-coherent memory regions for DMA ...
    (Linux-Kernel)
  • Re: High-performance IO
    ... The size of contigious buffer is meaningfull for common buffer DMA ... I would say that for scatter-gather DMA it depends on how much memory ... I know that AWE can give the programmer a way to use ...
    (microsoft.public.win32.programmer.kernel)