Two questions about the w2k/XP paging subsystem

  • Thread starter Thread starter Al Dykes
  • Start date Start date
A

Al Dykes

This seems to be the closest thing on my news server for a windows kernel
discussion group.

When an executable object is invoked and pages get sucked into
physical memory do the page get written to the swap file right away,
or ever if they havn't been made dirty.

Another question; If I split the swap space across two disks and the
time comes to write something in swap does the I/O system see if one
of the disks is busy and write to the shortest Q ?

Is there a web page overview that I can read ?

Thanks
 
This seems to be the closest thing on my news server for a windows
kernel discussion group.

When an executable object is invoked and pages get sucked into
physical memory do the page get written to the swap file right away,
or ever if they havn't been made dirty.

Another question; If I split the swap space across two disks and the
time comes to write something in swap does the I/O system see if one
of the disks is busy and write to the shortest Q ?

Is there a web page overview that I can read ?

Thanks
Click to expand...

I can answer the first question but not the second.

No an executable does not get paged out right away. It will stay in
memory while it is being processed. Depending on the load then it could
just get discarded and never get written to the page file. Also some
core type executables are flagged as non-pagable and will never get put
in the page file.

I don't know the logic of the disk I/O on the page file. I can say if
you have more than one physical drive and have different levels of load
on the drives you can always gain some performance by splitting the page
file. I always recommend doing it on any server under load.

Leonard Severt

Windows 2000 Server Setup Team
 
For more information about the paging file (and most other memory, caching,
etc. information), I strongly recommend Inside Windows 2000
(www.sysinternals.com).

A kernel discussion group is @ microsoft.public.win32.programmer.kernel. I
also recommend the WinDbg group as well.

As to the second question, the Memory Manager just writes to PageX, wherever
that page happens to be mapped to. The big perf gains come from separating
high I/O resources (e.g. Exchange/SQL Transaction Logs) from the page file.
Having the paging file on multiple spindles will generally help, but the
degree of performance gain is highly dependent on what the application(s)
are actually doing and the resources available to them (i.e. Large RAM
reserves with an app that batches its memory access will have little or no
perf gain with a multiple page file config vs. a RAM constrained config with
an app that is 'random' in allocations and tends to have large sparse areas
would see more perf gain).

Generally speaking it isn't the PageFile writes that are perf killers (they
are almost always done in the background by a utility thread), it is the
page reads that need to be optimized. A page read generally must complete
before whatever needed the information can continue, so to optimize for that
you would generally not want your writes to be 'random' b/c then you would
lose the read-ahead (harware and software) and other optimizations that help
w/the page-in perf.

For best perf w/a paging file, it is generally best to put it on a mirrored
partition. With 2 drives, create 2 partitions on each drive. Mirror the
first 2 partitions on each. Use the mirrored partitions for the OS and
paging file, the other 2 partitions for whatever data you want (you could
also combine these to create a larger volume). This will allow the
controller to make writes (and reads) from the disk with the smallest queue.

The downside is, of course, that the storage efficiency (overhead vs usable
bytes) is significantly lower than just creating a 2nd page file.

Pat
 
Al Dykes said:
This seems to be the closest thing on my news server for a windows kernel
discussion group.

When an executable object is invoked and pages get sucked into
physical memory do the page get written to the swap file right away,
or ever if they havn't been made dirty.
Click to expand...

Leonard Severt from MSFT answers this question, but I'd like to point out a
couple of other things:

The "code pages" from the executable are never written to the swap file.
These pages are memory mapped (read-only) to the original executable file.
The pages may be discarded if the kernel needs physical memory for something
else and the pages aren't locked. When the pages are needed again, they're
simply read from the original executable file using mapped I/O. No need to
involve the swap files.

And nothing ever gets written to the swap file "right away". Writing to the
swap file is a lazy process that happens on an "as needed" basis.

By the way, although you'd think so from its title, the
microsoft.public.win32.programmer.kernel newsgroup doesn't often talk about
issues like this. Its stated goal is to talk about things exported by
KERNEL32.DLL, which is far from what I think of when I think of the NT
"kernel" O/S. However, I think your question is fair game for that forum
since there's no other place.

Carl
 
Back
Top