GetProcessIoCounters
in [Win32 Kernel]
|
Prev: acheter ampicillin bon marche achat ampicillin canada au rabais en ligne sans prescription commander ampicillin canada soft un Achat de achat ampicillin en France avec livraison acheter ampicillin suisse soft bon marche
Next: ! lpc port Usage
From: Hugo gleaves on 8 Jul 2008 10:33 I'm a bit surprised that there isn't a general Win32 Developer group somewhere on this branch of the forums, if there is one elsewhere in here please do let me know. My question pertains to the above function. We have an app that uses a lot of mapped memory, we repeatedly do updates to it and periodically flush the modified pages. In addition we also call FlushFileBuffer and as explained in the MSDN documentation, this should cause the process to block until all modified pages are written to the disk. During timing tests the process does go much slower when we call FlushFileBuffers, so I believe it is indeed writing these to the disk. However we also call GetProcessIoCounters just before and just after, and see zero change all fields (except 'OtherOperationCount). We are very puzzled about this, surely flushing these pages constitutes a write operation? Is there anything wrong here or is there another way to find out this? We want to discover the actual number of bytes/pages that get flushed so we can tune memory use and stuff, being totally unable to measure the actual writes means we have no way to improve memory use or try different strategies. Any help much appreciated. Thanks
From: Alan Carre on 9 Jul 2008 15:08 "Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message news:FB59990E-E117-450B-81E3-6B9FF66E1F41(a)microsoft.com... > We have an app that uses a lot of mapped memory, we repeatedly do updates > to > it and periodically flush the modified pages. > > In addition we also call FlushFileBuffer and as explained in the MSDN > documentation, this should cause the process to block until all modified > pages are written to the disk. > > During timing tests the process does go much slower when we call > FlushFileBuffers, so I believe it is indeed writing these to the disk. > > However we also call GetProcessIoCounters just before and just after, and > see zero change all fields (except 'OtherOperationCount). Have you run the same experiment before and after writing to the file using WriteFile? WriteFile is obviously considered to be an I/O operation regardless of whether or not the system decides to commit the written data do disk (or named pipe, or any other I/O device). FlushFileBuffers on the other hand is not an I/O operation in the same sense. That is, nothing is being inputted or outputted to or from your program. Flushing, I would think, is best described as a synchronization operation between the kernel and the storage device. Perhaps the change in the 'Others' is a reflection of that fact. It should be easy enough to test this assertion. Simply create a file in the normal way. GetIoCounters, save off result. Write "Hello World" to the file, GetIoCounters again and see if it went up by 1. Check "others" to verify that it didn't change (assuming buffering is enabled). Next FlushFileBuffers and GetIoCounters again. In this case you should see "others" increase by 1 IF it is tracking synchronization IO events (though this is not sufficient evidence from a logical point of view). IO should not increase but you already know that. If the above happens to come out as expected then you know 1 thing, and have a hint about another: 1. WriteFile is an IO operation even if nothing is written to disk 2. The Others field *possibly includes* synchronization IO events such as flushing. To verify 2, you could devise more elaborate experiements with different sized file buffers and write operations. You could run random writes of varying sizes to a buffered file, check the sum of WriteOperationCount and Other(Transfers/Operation)Count is exactly the same no matter what the sequence or sizes of the write operations are (with total bytes written being constant obviously). Then you could repeat the experiment with FILE_FLAG_NO_BUFFERING and see if the two counts are identical after each WriteFile operation. In any case, I wouldn't rely on "Other(Transfers/Operation)Count" even if the above experiments were consistent with the assumption. I haven't come accross any documentation on how to determine exactly how much data is transfered to physical storage (by *any* write operation) other than WriteFile to an unbuffered file (in which case it's just the number of bytes written). - Alan Carre
From: m on 9 Jul 2008 18:00
Use perfmon to profile your application performance FlushFileBuffers does not cause a change in the values reported by GetProcessIoCounters because it is just an IOCTL to the FS that requests that the file cache(s) be committed to persistent storage "Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message news:FB59990E-E117-450B-81E3-6B9FF66E1F41(a)microsoft.com... > I'm a bit surprised that there isn't a general Win32 Developer group > somewhere on this branch of the forums, if there is one elsewhere in here > please do let me know. > > My question pertains to the above function. > > We have an app that uses a lot of mapped memory, we repeatedly do updates > to > it and periodically flush the modified pages. > > In addition we also call FlushFileBuffer and as explained in the MSDN > documentation, this should cause the process to block until all modified > pages are written to the disk. > > During timing tests the process does go much slower when we call > FlushFileBuffers, so I believe it is indeed writing these to the disk. > > However we also call GetProcessIoCounters just before and just after, and > see zero change all fields (except 'OtherOperationCount). > > We are very puzzled about this, surely flushing these pages constitutes a > write operation? > > Is there anything wrong here or is there another way to find out this? > > We want to discover the actual number of bytes/pages that get flushed so > we > can tune memory use and stuff, being totally unable to measure the actual > writes means we have no way to improve memory use or try different > strategies. > > Any help much appreciated. > > Thanks > |