Re: Performance problem with UnmapViewOfFile() in Vista and XP x64
- From: "Pavel Lebedinsky [MSFT]" <pavel@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 12 Mar 2007 06:08:29 -0700
As far as I know, no further changes are planned in this area
for SP1.
The behavior you're seeing is considered to be by design.
When you unmap a view, pages from the view are removed
from your working set and placed onto the modified page list
(assuming they are not part of any other working set). At this
point the memory manager may begin flushing them to disk.
There is no mechanism by which an application can tell the
system that some of the modified pages shouldn't be written
out because they will soon be referenced back into the
working set.
So even on XP you will get some paging IO in this case
(you can see it by monitoring Memory\Pages Output/sec
counter in perfmon). When the number of modified pages
is low you may not see any paging IOs. As it gets higher,
XP will try to write out about 100 pages every second.
Finally, when available pages (free+zeroed+standby) drop
below about 1000, the modified page writer on XP will
start writing as fast as it can.
Vista has several changes in this area. When the number of
modified pagefile pages is low it should actually write less
often than XP (this helps battery life on laptops). However,
Vista also switches to the "continuous write" mode sooner
than XP, to prevent problems when misbehaving applications
fill entire memory with dirty pages. In LH/Vista SP1 the
thresholds have been somewhat relaxed compared to
Vista RTM but they are unlikely to go back to XP levels.
I can't think of a good solution to this. On 64 bit the address
space is large enough so that you can keep everything in
the working set as long as there is enough physical memory
to back it. On 32 bit however you can have more RAM than
VM space, so unmapping becomes necessary. You could
use multiple processes to hold portions of the entire region
in their working sets, but that will likely require significant
design changes and may not be a feasible solution.
If you are not actually sharing the memory among multiple
processes (in effect, using a pagefile backed section as a
cache for a single process) then you might be able to use
AWE memory instead.
Finally, you could also write a driver to lock your shared
pages in memory so they are never paged out even if you
unmap them. This is rather ugly but might help if you have
no other options.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
"chaboud" wrote:
I tried this with the LH Feb '07 CTP, and that did not correct the problem.
If this is roughly the state that the kernel will be in for Vista SP1,
we'll
have to find a workaround, feature limitation for Vista, or, at the very
least, warn our users about the issue.
In the context in which we use this technique (an HD video editor) we can
see a significant performance loss, from 20fps playback in XP 32 to 5fps
in
Vista 32 on the same hardware. Because of virtual-address-space
size-limits
and fragmentation, it is not possible to avoid unmapping without severely
limiting the amount of usable memory for these buffers. Limiting this
cache
size would lead to a performance/usability limitation, so any such change
would have to be restricted to Vista.
We'd very much like to find a clean resolution to this if at all possible.
.
- References:
- Prev by Date: RE: Performance of RevertToSelf and ImpersonateLoggedOnUser
- Next by Date: Re: Performance problem with UnmapViewOfFile() in Vista and XP x64
- Previous by thread: Re: Performance problem with UnmapViewOfFile() in Vista and XP x64
- Next by thread: Re: Performance problem with UnmapViewOfFile() in Vista and XP x64
- Index(es):
Relevant Pages
|
