How is this different from, say, booting Windows without a paging file? Or am I missing the point entirely…
Peter
OSR
[quote]
If I were to be king for a day I would build a test OS with all virtual memory resident and then start counting how much the world would be a better place. [/quote]
Ironically, his is how Windows works when demand for memory is not that heavy - although
infrequently accessed pages get removed from the working set, they don’t get paged to the disk unless you are low on RAM. Therefore, handling page fault is in these cases is just about bringing a page back to the working set…
Anton Bassov
wrote in message news:xxxxx@ntdev…
>
>
> How is this different from, say, booting Windows without a paging file?
> Or am I missing the point entirely…
>
I also think that is a good idea and without access to source I think I have
lack of insight to answer that exactly, this is also why I would like to be
king. But what I am dreaming about is:
-no more need for distinction between NPP and PP
-no more need for locking buffers and less mapping required
-no need to copy buffers between scarce NPP and PP because of IRQL
constraints
-reduced exception handling needed to handle page faults
I am still using page files because I will not receive crash dumps
otherwise.
//Daniel
Can you explain why would the performance increase be “incredible”?
Right now, frequently hit code paths are kept paged in, so there isn’t a performance loss there.
Unless you’re talking about when the system has insufficient physical memory to contain its working set. Things get slow, here, yes - but they would simply grind to a halt and fall over and die on such a system with no in-paging support. I’m not sure that’s such a performance increase either.
- S
-----Original Message-----
From: xxxxx@resplendence.com
Sent: Friday, February 20, 2009 09:33
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PASSIVE_LEVEL code while paging file is unavailable
The way I see it, even though there is a paging file you cannot push it very
far. If you make this much bigger than your actual amount of RAM, above a
certain threshold you will see a sharp drop in usability and scalability.
It’s just a way of pretending to have just the double of what you actually
own which looks kind of greedy.
If I were to be king for a day I would build a test OS with all virtual
memory resident and then start counting how much the world would be a better
place. The performance increase I imagine to be incredible and I am
foreseeing low latencies and predictability in the time domain with the
absence of an expensive page fault handler which needs to read in pages from
disk.
//Daniel
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> At the moment, we’re very concerned with the number of VMs we can run on a
> single machine. If we got rid of the page file, then we just have to put
> it back at the virtualization layer, and we’d have a lot less information
> about what’s worth paging.
>
> I’ve heard your argument a lot lately. Please understand that we
> experience huge memory pressure all the time. Everybody would like to get
> just one more VM running well.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Team
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------
>
> wrote in message news:xxxxx@ntdev…
>> Yes that’s a feature that made sense when systems had only 16MB of RAM
>> available. That number has scaled with a factor of 1024 since then so I
>> just cannot understand why they don’t do efforts to get rid of the page
>> file altogether.
>>
>> //Daniel
>>
>>
>>
>> wrote in message news:xxxxx@ntdev…
>>> “In general, unless explicitly specified otherwise, most PASSIVE_LEVEL
>>> routines
>>> are pagable.”
>>>
>>> I think Vista/Win2008 finally almost got rid of that insanity. They
>>> don’t seem to page the kernel stacks out anymore, but still contain
>>> pageable code, which occasionally gets in the way of the power
>>> management.
>>>
>>
>>
>
—
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
This is false, at least part of it. Locking buffers is needed also to prevent the user from unmapping or reprotecting them out from under the kernel.
When would you have reduced need for exception handling? You would absolutely still need to try/except across accesses to user buffers, for the same reason as before. That sort of thing is not related to a lack of in-paging.
In-paging failure was almost always fatal before except in cases like user-mapped data section views. You could never protect against a failure to in-page something like part of a kernel stack with a try/except.
- S
-----Original Message-----
From: xxxxx@resplendence.com
Sent: Friday, February 20, 2009 10:01
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PASSIVE_LEVEL code while paging file is unavailable
wrote in message news:xxxxx@ntdev…
>
>
> How is this different from, say, booting Windows without a paging file?
> Or am I missing the point entirely…
>
I also think that is a good idea and without access to source I think I have
lack of insight to answer that exactly, this is also why I would like to be
king. But what I am dreaming about is:
-no more need for distinction between NPP and PP
-no more need for locking buffers and less mapping required
-no need to copy buffers between scarce NPP and PP because of IRQL
constraints
-reduced exception handling needed to handle page faults
I am still using page files because I will not receive crash dumps
otherwise.
//Daniel
—
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
I try to keep my systems with at least 4GB of memory for 32-bit OS versions.
I reduces paging a lot and I prefer a notebook with a 7200 RPM drive just to
help, but with the limited address range there is some paging going on. I
also try and keep only what I need loaded as I hate a crowded taskbar and I
am basically a single threaded human. I keep Outlook Express to only
checking every hour for new messages in both email and newsgroups. However,
that says more about me than the OS or the computer. One place where paging
is desirable is multiple copies of some program where if it is big enough,
such as Visual Studio, the data sections need to be paged out. I can’t
really do a lot of work on multiple projects at once, but I may need one for
reference or to copy code from one to the other. Add in the docs for MSDN
Library and maybe a WDK or two and a 32-bit OS just doesn’t have enough real
memory to keep everything in memory.
I yearn for the day when I can load up a notebook with enough memory to
avoid paging, but most have only two SODIMM slots. That is a major issue
for installing 16GB of memory and using a 64-bit OS even without the
problems most of us see with inadequate support for drivers and application
written as 64-bit. It appears only Linux and the MAC have full 64-bit
support. It will get here some time in the future and the push with Server
2008 R2 being only released in 64-bit versions may help over time, but it
will still have 32-bit support in the application arena. Look how long it
took Microsoft to kill the 16-bit environment for applications.
wrote in message news:xxxxx@ntdev…
> wrote in message news:xxxxx@ntdev…
>>
>>
>> How is this different from, say, booting Windows without a paging file?
>> Or am I missing the point entirely…
>>
>
> I also think that is a good idea and without access to source I think I
> have lack of insight to answer that exactly, this is also why I would like
> to be king. But what I am dreaming about is:
>
> -no more need for distinction between NPP and PP
> -no more need for locking buffers and less mapping required
> -no need to copy buffers between scarce NPP and PP because of IRQL
> constraints
> -reduced exception handling needed to handle page faults
>
> I am still using page files because I will not receive crash dumps
> otherwise.
>
> //Daniel
>
>
>
“Skywing” wrote in message
news:xxxxx@ntdev…
>>Can you explain why would the performance increase be “incredible”?
Run without a paging file and see for yourself how responsive the system
becomes. I don’t understand why paging files need to be switched ON on all
flavors of the OS.
>>Right now, frequently hit code paths are kept paged in, so there isn’t a
>>performance loss there.
It’s not just about code but about data and it’s not just about performance
but about latency as well. Just the sudden need to go through the filesystem
is creating lots of latency which means just missing the boat if you are
doing say audio.
>>Unless you’re talking about when the system has insufficient physical
>>memory to contain its working set. Things get slow, here, yes - but they
>>would simply grind to a halt and fall over and die on such a system with
>>no in-paging support. I’m not sure that’s such a performance increase
>>either.
Things will eventually grind to a halt anyhow no matter what. The idea that
the paging file can grow forever is nothing but theoretical and not usable
in practice. I/O through the file system is XXX times slower than RAM, you
just cannot push this very far. I remember pressing the reset button on a
system that becomes unresponsive because of memory consumption.
It will dramatically simplify the system as there is no more need to
adminster different kinds of memory pools resulting in less fragmentation.
There will be much less need to schedule things around because of IRQL
restrictions (such as work items etc). There will be no more need to check
if virtual addresses are locked down and a lot of obsolete code can just be
eliminated because it doesn’t need to accomodate the DISKRAM paradigm
anymore.
It was designed like that many years ago, the question is if this still
makes sense today. I think nobody can oversee this equation until it’s
carried out for real.
//Daniel
-----Original Message-----
From: xxxxx@resplendence.com
Sent: Friday, February 20, 2009 09:33
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PASSIVE_LEVEL code while paging file is unavailable
The way I see it, even though there is a paging file you cannot push it very
far. If you make this much bigger than your actual amount of RAM, above a
certain threshold you will see a sharp drop in usability and scalability.
It’s just a way of pretending to have just the double of what you actually
own which looks kind of greedy.
If I were to be king for a day I would build a test OS with all virtual
memory resident and then start counting how much the world would be a better
place. The performance increase I imagine to be incredible and I am
foreseeing low latencies and predictability in the time domain with the
absence of an expensive page fault handler which needs to read in pages from
disk.
//Daniel
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> At the moment, we’re very concerned with the number of VMs we can run on a
> single machine. If we got rid of the page file, then we just have to put
> it back at the virtualization layer, and we’d have a lot less information
> about what’s worth paging.
>
> I’ve heard your argument a lot lately. Please understand that we
> experience huge memory pressure all the time. Everybody would like to get
> just one more VM running well.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Team
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------
>
> wrote in message news:xxxxx@ntdev…
>> Yes that’s a feature that made sense when systems had only 16MB of RAM
>> available. That number has scaled with a factor of 1024 since then so I
>> just cannot understand why they don’t do efforts to get rid of the page
>> file altogether.
>>
>> //Daniel
>>
>>
>>
>> wrote in message news:xxxxx@ntdev…
>>> “In general, unless explicitly specified otherwise, most PASSIVE_LEVEL
>>> routines
>>> are pagable.”
>>>
>>> I think Vista/Win2008 finally almost got rid of that insanity. They
>>> don’t seem to page the kernel stacks out anymore, but still contain
>>> pageable code, which occasionally gets in the way of the power
>>> management.
>>>
>>
>>
>
—
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
Actually, there’s a tremendous body of academic study and empirical evidence
that some code and data get used a lot and some get few references. Paging
is a way to keep the stuff with the most frequent references in memory,
increasing the utilization of the RAM that the customer bought.
You’re essentially making the argument that we should just all buy enough
extra RAM that the programming problem is simplified. I’d actually buy that
argument for client machines with no virtualization.
For servers, though, there is never enough RAM to do the job. It’s always a
cost/benefit tradeoff. More RAM costs more, consumes more motherboard
space, consumes more power and comes with a higher error rate. More power
adds to the cooling cost.
By using paging, we push up the utilization on whatever RAM we have. Pages
that are possible to move out to a swap file but aren’t marked as pageable
almost always then suffer lower utilization than surrounding pages. That’s
just wasted money, power, cooling and reliability.
We actually do measure this internally. Every bit of memory we can scavenge
pushes up the number of transactions a server can process.
And if you don’t think this applies to you, wait until the world sorts out
client virtualization. It’s happening already, though not in a big way.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> The way I see it, even though there is a paging file you cannot push it
> very far. If you make this much bigger than your actual amount of RAM,
> above a certain threshold you will see a sharp drop in usability and
> scalability. It’s just a way of pretending to have just the double of what
> you actually own which looks kind of greedy.
>
> If I were to be king for a day I would build a test OS with all virtual
> memory resident and then start counting how much the world would be a
> better place. The performance increase I imagine to be incredible and I
> am foreseeing low latencies and predictability in the time domain with
> the absence of an expensive page fault handler which needs to read in
> pages from disk.
>
> //Daniel
>
>
>
>
> “Jake Oshins” wrote in message
> news:xxxxx@ntdev…
>> At the moment, we’re very concerned with the number of VMs we can run on
>> a single machine. If we got rid of the page file, then we just have to
>> put it back at the virtualization layer, and we’d have a lot less
>> information about what’s worth paging.
>>
>> I’ve heard your argument a lot lately. Please understand that we
>> experience huge memory pressure all the time. Everybody would like to
>> get just one more VM running well.
>>
>> –
>> Jake Oshins
>> Hyper-V I/O Architect
>> Windows Kernel Team
>>
>> This post implies no warranties and confers no rights.
>>
>> --------------------------------------------
>>
>> wrote in message news:xxxxx@ntdev…
>>> Yes that’s a feature that made sense when systems had only 16MB of RAM
>>> available. That number has scaled with a factor of 1024 since then so I
>>> just cannot understand why they don’t do efforts to get rid of the page
>>> file altogether.
>>>
>>> //Daniel
>>>
>>>
>>>
>>> wrote in message news:xxxxx@ntdev…
>>>> “In general, unless explicitly specified otherwise, most PASSIVE_LEVEL
>>>> routines
>>>> are pagable.”
>>>>
>>>> I think Vista/Win2008 finally almost got rid of that insanity. They
>>>> don’t seem to page the kernel stacks out anymore, but still contain
>>>> pageable code, which occasionally gets in the way of the power
>>>> management.
>>>>
>>>
>>>
>>
>
>
I did run Vista x64 without a page file for quite some time. At the end, though, with only 4GB of RAM, I was finding myself running out of commit given the amount of usage I was putting on the system. (Hooray for SearchIndexer wanting almost a *gigabyte* to itself. Even though it rarely touches this memory so that most of it could have been paged out, without a page file enabled, that RAM was just completely wasted.)
The main advantage that I saw here was that suspend/resume was much faster, as those code paths often got paged out as they weren’t frequently hit… until you suspended/resumed, in which case you had to wait a bit for things to grind away.
In general use, though, things were mostly the same.
Now, of course, the page file isn’t an unbounded resource. If you oversubscribe beyond your working set, then things are going to suck, performance wise. In such cases, one needs to get more memory on the box, or reduce the size of what needs to be in the working set.
There are some pathological cases where the working set can be pushed out of memory, though, which you can argue that running without a page file can provide some defense against. For example, large (cached) file copies often run a risk of triggering this behavior, as things get out-paged to make room for a large system cache. (I was sadden by the rolling back of the uncached I/O CopyFile change in Vista SP1, as it greatly reduced that annoyance, in my experience.)
Events like that which spike physical memory usage and cause portions of the real working set to be out-paged are a problem. However, I’m not sure that disabling the pagefile is really the right way to solve those issues. That’s more treating the symptoms than fixing the underlying problem.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Friday, February 20, 2009 5:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:PASSIVE_LEVEL code while paging file is unavailable
“Skywing” wrote in message
news:xxxxx@ntdev…
>>Can you explain why would the performance increase be “incredible”?
Run without a paging file and see for yourself how responsive the system
becomes. I don’t understand why paging files need to be switched ON on all
flavors of the OS.
>>Right now, frequently hit code paths are kept paged in, so there isn’t a
>>performance loss there.
It’s not just about code but about data and it’s not just about performance
but about latency as well. Just the sudden need to go through the filesystem
is creating lots of latency which means just missing the boat if you are
doing say audio.
>>Unless you’re talking about when the system has insufficient physical
>>memory to contain its working set. Things get slow, here, yes - but they
>>would simply grind to a halt and fall over and die on such a system with
>>no in-paging support. I’m not sure that’s such a performance increase
>>either.
Things will eventually grind to a halt anyhow no matter what. The idea that
the paging file can grow forever is nothing but theoretical and not usable
in practice. I/O through the file system is XXX times slower than RAM, you
just cannot push this very far. I remember pressing the reset button on a
system that becomes unresponsive because of memory consumption.
It will dramatically simplify the system as there is no more need to
adminster different kinds of memory pools resulting in less fragmentation.
There will be much less need to schedule things around because of IRQL
restrictions (such as work items etc). There will be no more need to check
if virtual addresses are locked down and a lot of obsolete code can just be
eliminated because it doesn’t need to accomodate the DISKRAM paradigm
anymore.
It was designed like that many years ago, the question is if this still
makes sense today. I think nobody can oversee this equation until it’s
carried out for real.
//Daniel
-----Original Message-----
From: xxxxx@resplendence.com
Sent: Friday, February 20, 2009 09:33
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PASSIVE_LEVEL code while paging file is unavailable
The way I see it, even though there is a paging file you cannot push it very
far. If you make this much bigger than your actual amount of RAM, above a
certain threshold you will see a sharp drop in usability and scalability.
It’s just a way of pretending to have just the double of what you actually
own which looks kind of greedy.
If I were to be king for a day I would build a test OS with all virtual
memory resident and then start counting how much the world would be a better
place. The performance increase I imagine to be incredible and I am
foreseeing low latencies and predictability in the time domain with the
absence of an expensive page fault handler which needs to read in pages from
disk.
//Daniel
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> At the moment, we’re very concerned with the number of VMs we can run on a
> single machine. If we got rid of the page file, then we just have to put
> it back at the virtualization layer, and we’d have a lot less information
> about what’s worth paging.
>
> I’ve heard your argument a lot lately. Please understand that we
> experience huge memory pressure all the time. Everybody would like to get
> just one more VM running well.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Team
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------
>
> wrote in message news:xxxxx@ntdev…
>> Yes that’s a feature that made sense when systems had only 16MB of RAM
>> available. That number has scaled with a factor of 1024 since then so I
>> just cannot understand why they don’t do efforts to get rid of the page
>> file altogether.
>>
>> //Daniel
>>
>>
>>
>> wrote in message news:xxxxx@ntdev…
>>> “In general, unless explicitly specified otherwise, most PASSIVE_LEVEL
>>> routines
>>> are pagable.”
>>>
>>> I think Vista/Win2008 finally almost got rid of that insanity. They
>>> don’t seem to page the kernel stacks out anymore, but still contain
>>> pageable code, which occasionally gets in the way of the power
>>> management.
>>>
>>
>>
>
—
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
>
Actually, there’s a tremendous body of academic study and empirical
evidence
that some code and data get used a lot and some get few references.
Paging
is a way to keep the stuff with the most frequent references in
memory,
increasing the utilization of the RAM that the customer bought.
I wish I could find a reference to the paper… someone did some tests
with Windows (and Linux I think) and paging. The outcome was that
Windows would swap stuff out even when there was heaps and heaps of
‘free’ memory, and the net result was a general improvement in
performance. The idea being that ‘free’ memory is used as buffer cache
(or whatever Windows calls it) so the more ‘free’ memory there is, the
more stuff from disk you can cache in memory.
The whole problem of course is that a ‘general improvement in
performance’ is a rather abstract thing. Windows doesn’t know that in 3
seconds time you might alt-tab to outlook and want to read an email, and
doesn’t know that the 500ms (longer if you are on a laptop and your disk
has spun down) that it spends swapping it back in is going to tick you
off. As a result of the swapping out of outlook, all the other stuff you
have been doing up until then has executed a few ms faster, but it’s the
delay after you alt-tab to outlook that you actually notice.
As they say, you can’t please all of the people all the time…
James
> Windows doesn’t know that in 3 seconds time you might
alt-tab to outlook and want to read an email, and doesn’t
know that the 500ms (longer if you are on a laptop and
your disk has spun down) that it spends swapping it back
in is going to tick you off. As a result of the swapping out
of outlook, all the other stuff you have been doing up
until then has executed a few ms faster, but it’s the delay
after you alt-tab to outlook that you actually notice.
Windows doesn’t just suddenly decide “let’s swap Outlook
to disk and use its memory for something else”. In order to
evict an active pagefile-backed page from memory, the
following sequence of events needs to happen:
-
The page needs to be trimmed from its working set. On XP
this can happen when the user minimizes an application, but
Vista/Win7 no longer empty the working set on minimize, so
the only way trimming can occur (unless the app explicitly
requests it with SetProcessWorkingSetSize or VirtualUnlock)
is if the memory manager detects some form of memory
pressure (available pages drop too low, or standby pages
are being repurposed, etc). -
If the page is dirty it is placed on the modified page list
where it typically sits for a few minutes or even longer before
being written to pagefile. -
The page is then placed at the end of the standby list
which is a FIFO queue (or several prioritized queues starting
with Vista). When the OS needs to allocate a physical page
it searches zeroed and free page lists first, and if both are
empty it takes a page from the front of the lowest-priority
standby list.
Your argument above basically states that Windows trims
pages too aggressively in step 1, hurting responsiveness
of scenarios like switching back to an app that has not been
used for a while. Other people in this thread said that
disabling pagefile improves responsiveness of such
scenarios by effectively preventing pages from leaving the
modified list in step 2.
Both of these statements can be true in some cases. But
in other cases the exact opposite can also be true. Not
trimming aggresively enough and/or running without
pagefile means that unused pages might be sitting in
working sets or on the modified list, reducing the amount
of data that can be cached in the system cache or on the
standby list. That in turn can mean that when you launch
your browser it will take 5 seconds instead of 500 ms
because it needs to read a lot of pages from disk, rather
than getting them from the cache.
Without looking at something like an xperf trace it is
impossible to say why a particular scenario is slow, and
therefore what can be done to improve it. In the “alt-tab
to Outlook” scenario above, it is quite possible that
Outlook has to hit the disk because it tries to read something
from its data files, or maybe it faults on code or resource
pages from its DLLs. If that’s the case then the advice
to disable the pagefile will only make things worse.
Note that I’m not claiming that Windows memory
management is perfect the way it is and cannot be improved.
I’m just saying that you can’t blame all responsiveness issues
on the fact that “Windows swaps too much”. Each
problematic senario needs to be carefully investigated to
see what’s really going on (and we really appreciate it
when people report such scenarios to us).
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
The particular situation that I find the most irritating is coming in to
work after a virus scan has run overnight. XP, anyway, seems to like to
trim the working sets of idle apps in order to increase the filesystem
cache, which results in *every single app I leave up* being paged out
when I get in in the morning. Every day, of course, since our silly MIS
people insist on having the scan run every night.
Is this because I have too little memory on this machine? Yes. Would
they be smarter and most cost efficient not to waste my time by buying
more memory. Yes. Are they likely to? Not really.
Vista supposedly fixes this… they’re not likely to upgrade to that
either :-). Maybe Windows 7 will finally save my sanity.
Pavel Lebedinsky wrote:
> Windows doesn’t know that in 3 seconds time you might
> alt-tab to outlook and want to read an email, and doesn’t
> know that the 500ms (longer if you are on a laptop and
> your disk has spun down) that it spends swapping it back
> in is going to tick you off. As a result of the swapping out
> of outlook, all the other stuff you have been doing up
> until then has executed a few ms faster, but it’s the delay
> after you alt-tab to outlook that you actually notice.Windows doesn’t just suddenly decide “let’s swap Outlook
to disk and use its memory for something else”. In order to
evict an active pagefile-backed page from memory, the
following sequence of events needs to happen:
The page needs to be trimmed from its working set. On XP
this can happen when the user minimizes an application, but
Vista/Win7 no longer empty the working set on minimize, so
the only way trimming can occur (unless the app explicitly
requests it with SetProcessWorkingSetSize or VirtualUnlock)
is if the memory manager detects some form of memory
pressure (available pages drop too low, or standby pages
are being repurposed, etc).If the page is dirty it is placed on the modified page list
where it typically sits for a few minutes or even longer before
being written to pagefile.The page is then placed at the end of the standby list
which is a FIFO queue (or several prioritized queues starting
with Vista). When the OS needs to allocate a physical page
it searches zeroed and free page lists first, and if both are
empty it takes a page from the front of the lowest-priority
standby list.Your argument above basically states that Windows trims
pages too aggressively in step 1, hurting responsiveness
of scenarios like switching back to an app that has not been
used for a while. Other people in this thread said that
disabling pagefile improves responsiveness of such
scenarios by effectively preventing pages from leaving the
modified list in step 2.Both of these statements can be true in some cases. But
in other cases the exact opposite can also be true. Not
trimming aggresively enough and/or running without
pagefile means that unused pages might be sitting in
working sets or on the modified list, reducing the amount
of data that can be cached in the system cache or on the
standby list. That in turn can mean that when you launch
your browser it will take 5 seconds instead of 500 ms
because it needs to read a lot of pages from disk, rather
than getting them from the cache.Without looking at something like an xperf trace it is
impossible to say why a particular scenario is slow, and
therefore what can be done to improve it. In the “alt-tab
to Outlook” scenario above, it is quite possible that
Outlook has to hit the disk because it tries to read something
from its data files, or maybe it faults on code or resource
pages from its DLLs. If that’s the case then the advice
to disable the pagefile will only make things worse.Note that I’m not claiming that Windows memory
management is perfect the way it is and cannot be improved.
I’m just saying that you can’t blame all responsiveness issues
on the fact that “Windows swaps too much”. Each
problematic senario needs to be carefully investigated to
see what’s really going on (and we really appreciate it
when people report such scenarios to us).
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
There is a SetSystemFileCacheSize api available on Srv03 (and thus also XP x64) that you can use to enforce a hard limit on how much memory the cache will consume. I have a lil cmdline app to twiddle that which I try to use before doing something that will do a lot of cached I/O in order to prevent it from paging the entire system out (assuming I remember beforehand).
- S
-----Original Message-----
From: Ray Trent
Sent: Monday, February 23, 2009 13:00
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PASSIVE_LEVEL code while paging file is unavailable
The particular situation that I find the most irritating is coming in to
work after a virus scan has run overnight. XP, anyway, seems to like to
trim the working sets of idle apps in order to increase the filesystem
cache, which results in every single app I leave up being paged out
when I get in in the morning. Every day, of course, since our silly MIS
people insist on having the scan run every night.
Is this because I have too little memory on this machine? Yes. Would
they be smarter and most cost efficient not to waste my time by buying
more memory. Yes. Are they likely to? Not really.
Vista supposedly fixes this… they’re not likely to upgrade to that
either :-). Maybe Windows 7 will finally save my sanity.
Pavel Lebedinsky wrote:
>> Windows doesn’t know that in 3 seconds time you might
>> alt-tab to outlook and want to read an email, and doesn’t
>> know that the 500ms (longer if you are on a laptop and
>> your disk has spun down) that it spends swapping it back
>> in is going to tick you off. As a result of the swapping out
>> of outlook, all the other stuff you have been doing up
>> until then has executed a few ms faster, but it’s the delay
>> after you alt-tab to outlook that you actually notice.
>
> Windows doesn’t just suddenly decide “let’s swap Outlook
> to disk and use its memory for something else”. In order to
> evict an active pagefile-backed page from memory, the
> following sequence of events needs to happen:
>
> 1. The page needs to be trimmed from its working set. On XP
> this can happen when the user minimizes an application, but
> Vista/Win7 no longer empty the working set on minimize, so
> the only way trimming can occur (unless the app explicitly
> requests it with SetProcessWorkingSetSize or VirtualUnlock)
> is if the memory manager detects some form of memory
> pressure (available pages drop too low, or standby pages
> are being repurposed, etc).
>
> 2. If the page is dirty it is placed on the modified page list
> where it typically sits for a few minutes or even longer before
> being written to pagefile.
>
> 3. The page is then placed at the end of the standby list
> which is a FIFO queue (or several prioritized queues starting
> with Vista). When the OS needs to allocate a physical page
> it searches zeroed and free page lists first, and if both are
> empty it takes a page from the front of the lowest-priority
> standby list.
>
> Your argument above basically states that Windows trims
> pages too aggressively in step 1, hurting responsiveness
> of scenarios like switching back to an app that has not been
> used for a while. Other people in this thread said that
> disabling pagefile improves responsiveness of such
> scenarios by effectively preventing pages from leaving the
> modified list in step 2.
>
> Both of these statements can be true in some cases. But
> in other cases the exact opposite can also be true. Not
> trimming aggresively enough and/or running without
> pagefile means that unused pages might be sitting in
> working sets or on the modified list, reducing the amount
> of data that can be cached in the system cache or on the
> standby list. That in turn can mean that when you launch
> your browser it will take 5 seconds instead of 500 ms
> because it needs to read a lot of pages from disk, rather
> than getting them from the cache.
>
> Without looking at something like an xperf trace it is
> impossible to say why a particular scenario is slow, and
> therefore what can be done to improve it. In the “alt-tab
> to Outlook” scenario above, it is quite possible that
> Outlook has to hit the disk because it tries to read something
> from its data files, or maybe it faults on code or resource
> pages from its DLLs. If that’s the case then the advice
> to disable the pagefile will only make things worse.
>
> Note that I’m not claiming that Windows memory
> management is perfect the way it is and cannot be improved.
> I’m just saying that you can’t blame all responsiveness issues
> on the fact that “Windows swaps too much”. Each
> problematic senario needs to be carefully investigated to
> see what’s really going on (and we really appreciate it
> when people report such scenarios to us).
>
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
—
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
Jake Oshins,
If you think that saving a couple (or ten) megabytes of non-paged memory per VM really buys you anything if you want to run many VMs, think again… It may buy you an illusion in your artificial test cases (2 VMs more), but in real life - nothing.
Ray and others,
Paging strategy of Windows cache and VM manager has been a favorite bitch of mine for quite long time. Imagine that you’re writing a DVD with a few 700 MB files, and open IE. After a while, it seems to get into “those badass 700MB files are more important than your pitiful EXEs” contest. It seems that EXE pages are suddenly in LIFO - last in first out - list, and the system falls into perpetual page-in mode. IE slows to the crawl. It’s like a function responsible for tracking “accessed” bit in the page tables doesn’t do its job. Does it only happen for image sections mapped to multiple processes?
I WISH that MS developers ONLY used low end almost-obsoleted single core machines. Then they would notice those runaway applications, like IE with JScript-heavy pages, and crappy state of SMB server/client CPU consumption, etc. MS world would be a happier place (other than their unhappy developpers forced to work with with real-world system).
xxxxx@broadcom.com wrote:
Jake Oshins,
If you think that saving a couple (or ten) megabytes of non-paged memory per VM really buys you anything if you want to run many VMs, think again… It may buy you an illusion in your artificial test cases (2 VMs more), but in real life - nothing.
That’s a fascinating assertion. Do you have any actual data to back
that up, or are you just making it up?
In fact, 10 megabytes of non-paged memory per VM can easily mean the
difference between running 20 VMs and running 200 VMs. This lesson was
learned long ago in the Citrix/Terminal Services world, where the same
matters of scale arose.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> xxxxx@broadcom.com wrote:
> Jake Oshins,
>
> If you think that saving a couple (or ten) megabytes of non-paged
memory
per VM really buys you anything if you want to run many VMs, think
again… It may buy you an illusion in your artificial test cases (2
VMs
more), but in real life - nothing.
>That’s a fascinating assertion. Do you have any actual data to back
that up, or are you just making it up?In fact, 10 megabytes of non-paged memory per VM can easily mean the
difference between running 20 VMs and running 200 VMs. This lesson
was
learned long ago in the Citrix/Terminal Services world, where the same
matters of scale arose.
It sounds like you are virtualising some really really lightweight
windows machines… can you clarify how much memory the sort of VM’s you
are talking about have each?
It isn’t hard to come up with obscure corner cases to back up your
argument, but IMHO windows just doesn’t ‘scale down’ to the sort of
environment you appear to be talking about.
10mb * 200VM’s equates to approximately 2GB of memory… adding 2GB of
memory to a server to get you 180 more VM’s appears to be the sort of
choice where the discussion about the choice costs way more than ‘just
doing it’. Ditto for adding another 2G to 100 physical machines.
James
I really don’t know much about how the performance of all of this works
out, but I don’t think that’s what really drives all of this.
Many IT folks and those who write the checks have and continue to buy in
to the idea of being able to consolidate all of their servers on to a
much smaller number of servers without incurring much performance loss
because all of their servers are underutilized, or something to that
effect. I really don’t how true this, neither do they and they probably
don’t care a whole lot either, as what they have budgeted around is the
idea that this will save them money, not that it will perform close to
as well are at least adequately. They’re assuming that it will, because
it’s what every virtualization vendor tells them in the form of
marketing, and it’s also what every page in the veritable avalanche of
the usual marketing-presented-as-science from places the like Gartner
group et. al. also says. So, if it happens not to turn out to be true
in their particular case (which no study can predict anyway), at that
point, what whatever their original intentions regarding performance
were, unless they are willing to announce their failure, and pay still
more, they’re committed to the idea that ‘the tradeoff is acceptable,’
which makes it very easy for them to just keep consolidating. In the
worst case scenario, ‘unacceptable’ is only implicitly defined to mean
something like ‘until it breaks or people get really pissed off and
those savings are no longer worth the mutiny.’
I’m not saying that’s the only reason every MB matters - it clearly
isn’t - but what I just described is in my opinion quite common and
accordingly a lot of the market, so msft and everyone else has to take
that in to consideration.
mm
James Harper wrote:
> xxxxx@broadcom.com wrote:
>> Jake Oshins,
>>
>> If you think that saving a couple (or ten) megabytes of non-paged
memory
> per VM really buys you anything if you want to run many VMs, think
> again… It may buy you an illusion in your artificial test cases (2
VMs
> more), but in real life - nothing.
> That’s a fascinating assertion. Do you have any actual data to back
> that up, or are you just making it up?
>
> In fact, 10 megabytes of non-paged memory per VM can easily mean the
> difference between running 20 VMs and running 200 VMs. This lesson
was
> learned long ago in the Citrix/Terminal Services world, where the same
> matters of scale arose.
>It sounds like you are virtualising some really really lightweight
windows machines… can you clarify how much memory the sort of VM’s you
are talking about have each?It isn’t hard to come up with obscure corner cases to back up your
argument, but IMHO windows just doesn’t ‘scale down’ to the sort of
environment you appear to be talking about.10mb * 200VM’s equates to approximately 2GB of memory… adding 2GB of
memory to a server to get you 180 more VM’s appears to be the sort of
choice where the discussion about the choice costs way more than ‘just
doing it’. Ditto for adding another 2G to 100 physical machines.James
Tim,
In Citrix/TS world, the sessions were not virtual machines. They were sharing the kernel and (I guess) read-only file-mapping objects for system DLLs and EXEs. The typical installed memory I suppose was an order of magnitude less that in modern times.
In VM world, if you give each VM non-pageable memory (the host doesn’t do paging for VMs), you have to provide each one with decent amount of memory, say at least 512 MB. In this case, 10 MB per VM don’t change a thing.
>> The particular situation that I find the most irritating is
> coming in to work after a virus scan has run overnight.
> XP, anyway, seems to like to trim the working sets of idle
> apps in order to increase the filesystem cache, which results
> in *every single app I leave up* being paged out when I get
> in in the morning.There is a SetSystemFileCacheSize api available on Srv03
(and thus also XP x64) that you can use to enforce a hard
limit on how much memory the cache will consume. I have
a lil cmdline app to twiddle that which I try to use before
doing something that will do a lot of cached I/O in order to
prevent it from paging the entire system out (assuming
I remember beforehand).
This particular problem can occur even if the system
cache working set doesn’t grow very large. It’s called “standby
list erosion”, because background apps that process a lot of
files end up filling the entire standby list with the contents of
the files being processed, pushing other useful pages out of
RAM. There are several changes in Vista/Win7 that address
this:
-
Working set is no longer emptied when an application
window is minimized (so pages stay in the working set longer) -
Standby list was split into several sub-lists for pages with
different priorities. Background apps can be configured to
run with low memory priority so they won’t consume normal
priority pages. -
When superfetch is running, it can promote most often
used pages to higher-than-normal priority, and it can
proactively load other commonly used pages into memory
if there is a surplus of free/zeroed pages.
Applications can also do a few things to help prevent this
problem (even on XP) - such as using
FILE_FLAG_SEQUENTIAL_SCAN or non-cached IO
where appropriate.
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
> Paging strategy of Windows cache and VM manager has been
a favorite bitch of mine for quite long time. Imagine that you’re
writing a DVD with a few 700 MB files, and open IE. After a
while, it seems to get into “those badass 700MB files are more
important than your pitiful EXEs” contest. It seems that EXE
pages are suddenly in LIFO - last in first out - list, and the
system falls into perpetual page-in mode. IE slows to the crawl.
It’s like a function responsible for tracking “accessed” bit in the
page tables doesn’t do its job.
I believe there are several known reasons for this (like pages in
the system cache working set not being aged fast enough).
If people still see this or other similar issues in win7 I’d appreciate
it if you could send the details on how this can be reproduced to
pavel at microsoft.com (you could also post them here but I think
it might be a bit off-topic).
I WISH that MS developers ONLY used low end almost-
obsoleted single core machines. Then they would notice those
runaway applications, like IE with JScript-heavy pages, and
crappy state of SMB server/client CPU consumption, etc.
I actually agree with this. I’m just a lowly tester but I try to do
my part by keeping a 1 GHz Pentium 3 machine with 1 GB
of RAM. It runs Windows 7 (not a clean install - it’s been
upgraded through various intermediate builds of Vista and
Win7), Outlook, the Windows build environment, various
internal apps etc. I use it periodically when my main machine
(3 year old amd64 with 2 GB of RAM) is being upgraded or
debugged.
However, if you look into what it takes to make Windows
run well on this kind of hardware, you’ll find that there is
virtually no low hanging fruit. A typical Windows system
has hundreds if not thousands of individual components,
and it’s highly unlikely that any given change/bugfix would
give you more than 1% improvement in overall memory
usage, disk IO or CPU cycles. But hundreds of such
changes combined can make a lot of difference.
This by the way is another reason (besides VM density)
why we still care about paged code. A few pages per driver
doesn’t sound like much, but if you want to improve the
memory footprint of Windows, or at least make sure it
doesn’t regress too much from the previous release, you
have to worry about things like that (plus dozens of other
similarly small things).
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.