>and result is that using mapped file is ~ 10 times faster than using
ZwReadFile (on checked Windows 7)
Perf measurements on checked Windows are next to invalid.
Your customers will use free build. Measure there.
BTW - you can also use MDL read/write APIs which SRV uses.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>now almost equal, hooray.
You can also use MDL I/O.
To write to the file, use “prepare MDL write”, this returns you the MDL of the mapped file range, just update the data described by it and call “MDL write complete”.
Similar sequence is for read.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
You need to be careful when using FILE_FLAG_RANDOM_ACCESS with very large files. It can cause the system cache working set to increase to the point where it will start hurting performance of other processes.
You can have the same problem with your own file mapping if the file is larger than the amount of available memory. Here again you can either consume as much memory as you can (until the memory manager steps in and starts trimming you), or you can try to be nice to other processes and proactively unmap (or trim, by calling VirtualUnlock) areas of the file that you don’t need right now.
Accessing data that has been trimmed or unmapped (either by you, or by the cache manager) will require soft-faulting it from the standby list which is slower than a simple memcpy from a mapping that already points to the right physical pages, but it is still much faster than disk IO.
…and result is that using mapped file is ~ 10 times faster than using ZwReadFile (on checked Windows 7)
Checked builds add significant overhead to the access fault path. I suspect you’ll see less difference on free.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, May 9, 2012 7:10 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ZwCreateSection and extending the section
Excellent! That was going to be my suggestion, glad to hear it had that much of an impact. Without this flag the Cache Manager assumes sequential access, so you’ll get read ahead and more aggressive unmapping of areas you’ve behind your current location. Definitely not what you want in your case.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst OSR Open Systems Resources, Inc.
http://www.osronline.com
“Robert Goldwein” wrote in message news:xxxxx@ntdev…
Well, now I know.
I knew that flag FILE_RANDOM_ACCESS serves as a hint for FS how to treat files; in MSDN, this flag is described as "Access to the file can be random, so no sequential read-ahead operations should be performed by file-system drivers or by the system. " Nevertheless, this mere hint changes everyting - the performance of ZwReadFile and file mapping is now almost equal, hooray.
Thank you all for your input.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, May 09, 2012 09:30
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ZwCreateSection and extending the section
On 5/8/2012 11:40 PM, Robert Goldwein wrote:
[…] it seems that ZwReadFile
with caching is really much worse (performance) than file mapping -
and
I have no idea why.
How about using kernrate to find out where the extra time is spent?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer