On Win 2k, needing a large area of contiguous physical memory MAXMEM in
boot.ini has been used to reserve it.
A device driver creates a section for this physical memory and maps it into
user space. The user program needs to read from disk into this mapped
section.
I am not directly involved with this problem so I can not say what those
that are have been trying but they are not getting sufficient throughput,
much less than the same code reading into a buffer allocated by the OS.
It would appear reads to the mapped section are read somewhere else (the
cache?) and copied into the section by the processor.
Assuming the file is opened with CreateFile using FILE_FLAG_NO_BUFFERING
and the various alignment requirements of this flag are obeyed should I
expect the file to be busmastered directly into the physical memory of this
section?
>Assuming the file is opened with CreateFile using FILE_FLAG_NO_BUFFERING >and the various alignment requirements of this flag are obeyed should I >expect the file to be busmastered directly into the physical memory of this >section?
…later
I just lashed something up on my rather lesser machine with IDE drives and 1GB of RAM.
Mapping 768MB I appear to be able to fill it at around 48MB/s with 2% CPU usage. That was from a single IDE drive on a cheap PCI controller.
Only thing I noticed was an out of resources error if I tried to read more than about 60MB at a time (insufficient nonpaged pool?).
Removing FILE_FLAG_NO_BUFFERING I get 10MB/s and 8% CPU usage - which seems pretty conclusive.
Any clues why it might be different on different hardware? Adaptec SCSI controllers? Would reading from an OS striped set hurt it?