Preventing pageouts - an interesting technical challenge

[Andrew Mayo]

As with all demand paged virtual memory operating systems, Windows
uses a LRU algorithm to determine when a memory page can be stolen.

Even on systems where the virtual memory commit is not substantially
greater than the actual physical memory, this has the side-effect that
pages which have not been touched recently are likely to be stolen by
routine system tasks, such as services, which run continuously.

Now, the issue here is that we have some software - a large and fairly
complex app, that uses MSDE - and where the user might be interacting
with it and then go off to lunch. When they come back, some code and
data has been stolen by other tasks, and consequently there will be a
flurry of pagefaults as soon as the user starts interacting with the
program again.

They perceive this as poor and erratic performance, even though once
they've done something, it'll be quick again. Alas, there are lots of
'corners' they can go into before things are fast again.
Unfortunately, adding a reasonably generous amount of physical memory
doesn't seem to help a great deal. There are enough processes running
all the time that even with quite a large amount of physical memory,
sooner or later - and an hour is a long time in scheduling terms -
that application memory is gonna get stolen (SQL Server is probably a
prime culprit here, I suspect, even with its memory upper limit
configured to a fixed amount).

My question is. Is there any way to indicate to the OS that a
particular process is to have priority in the sense that its memory
pages are not to be stolen UNLESS absolutely necessary. Does running
the process with a higher scheduling priority (using 'start') affect
the paging algorithm in any way such that process pages are less
likely to be stolen. Or is the only cure to add so much physical
memory that the virtual commit is less than physical memory?

NB: you can see this phenomenon in standard Windows apps - e.g Word.
Use word and then leave it idle for a while (but don't do anything
else on the PC). After you return, try invoking some less-used
function - options dialogues, spell checking etc - and note that the
system will fault the code and data in from disk. After this the
function is quite fast until you leave the system idle for an hour or
so, after which you will observe that re-using the function will again
fault pages in.

 

[Alex Nichol]

My question is. Is there any way to indicate to the OS that a
particular process is to have priority in the sense that its memory
pages are not to be stolen UNLESS absolutely necessary. Does running
the process with a higher scheduling priority (using 'start') affect
the paging algorithm in any way such that process pages are less
likely to be stolen. Or is the only cure to add so much physical
memory that the virtual commit is less than physical memory?

AFAIK there is none (other than an ability in writing the code to lock
pages into the non-pageable pool, which is *not* something to be done by
any regular application). The system puts all applications on an equal
footing, and will use LRU to page out. When a process starts up again,
pages will be demand paged in, and will push out other tasks that have
not been recently in use. Whether you could get some benefit out of
having the user formally logout and another logon using FUS, I doubt -
and you are probably doing that anyway.

 

[Andrew Mayo]

AFAIK there is none

Thanks. I feared this was the case. I guess it will boil down to
trying to educate the customers on this. Unfortunately they are
migrating from a DOS-based application - one that many of them are
still perfectly happy with - and don't necessarily see Windows as an
advantage to them - so this is a BIG problem....

 

[Alex Nichol]

Thanks. I feared this was the case. I guess it will boil down to
trying to educate the customers on this. Unfortunately they are
migrating from a DOS-based application - one that many of them are
still perfectly happy with - and don't necessarily see Windows as an
advantage to them - so this is a BIG problem....

Well, you might start by pointing out that if it were still DOS only one
app could run at a time, so if they went away and someone else had been
using the machine, they would be loading everything themselves from
scratch

 

[Andrew Mayo]

Well, you might start by pointing out that if it were still DOS only one
app could run at a time, so if they went away and someone else had been
using the machine, they would be loading everything themselves from
scratch

Believe it or not, this would cut no ice. This is a dedicated system
and as far as they are concerned, performs one, and only one task, 8
hours a day. Unfortunately Windows wasn't designed with the idea that
a dedicated application would always run as the sole foreground
application with which the user would interact - other examples being
point of sale terminals, railway timetable displays and so forth.

What we need is a 'give paging priority to this foreground
application' as a switch so that all pages owned by a specific task
would sort to the end of the LRU list wrt the paging policy of the VM
subsystem. If the machine is so memory-starved that it MUST steal one
of those pages, it would then do so, otherwise, other pages are stolen
in preference. This is similar to the way dirty pages are lower in the
sort order for stealing because of the higher cost of stealing them.

I'd guess that application dedicated pages would still collate higher
than dirty pages in this revised algorithm, but, hey, it ain't gonna
happen.

I'm gonna ask the Linux people about this one and see what they have
to say, just out of interest...