Re: Att. Alex Nichol -VM cont.

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 12/28/04 

Date: Tue, 28 Dec 2004 18:53:30 +0200

On Mon, 27 Dec 2004 11:29:04 -0800, "Joshua Bolton"

>Hi Cquirke:

Hi!

>> Have you got a URL for that?
>Yes. There are two of them and they are in the first post of this thread

Sorry, I only have the last 2 posts. XP General cracks upto 1000 a
day, and I don't even parse all the headers, so the original posts in
this thread are beyond by newsreader's recall.

>> "AFAIK the original 386 design hard-coded virtual memory paging in 4k
>> blocks, which fits 4k clusters quite nicely." and "This virtual paging
>> isn't related to segment size, BTW".
>Do you have a URL for this? Anything from MS saying 4kb clusters are
>optimal for pagefile.sys? A source for the reason behind this?

Only old paper, I'm afraid: "Programming the Intel 80386" by Bud E
Smith and Mark T Johnson from 1987, page 285:

"An 80386 page is a 4 Kb-sized piece of memory (some other computers
use other page sizes). A page may start at any point in memory, but
for convenience's sake pages are usually placed at addresses 4k apart
(page frames). The addresses of page frames are 0, 4 Kb, 8 Kb, 16 Kb
etc. Any data item that starts at one of these addresses is said to be
"aligned on a page boundry". Addressing a page frame in the 4 Gb
linear address space is made easier because only a 20-bit address is
needed; the last 12 of the total 32bits in the address are all zeros."

When they speak of "other computers", they are not talking 486 etc. as
at this time, the 386 was still dripping amniotic fluid. :-)

>My first point is that from the Intel and Microsoft urls I find both
>manufacturers support for large memory pages [2 or 4meg pages].

If you mean 4k, 2M or 4M pages, then I doubt whether anything is going
to use the large page sizes for paging as we know it. If you mean
pick a number between 4k and 2M" then I'd want to know at what place
in the 386+ series this came in; Intel may have added something that
MS hasn't used. After all, for us consumers, it took MS until 1995 to
harness the full benefits of the 386 design :-)

>No where can I find documentation that says a 4kb page in memory
>is written to the hard drive ie. pagefile.sys in 4kb incriments.

Alas, this book gives a surfeit of such detail!

"A physical address has three parts: a 10-bit DIR entry, a 10-bit PAGE
entry, and a 12-bit OFFSET (see Figure 5-3). These three fields are
used to generate a physical address in the following way:

1. The 32-bit CR3 register holds the address of the current Page
Directory. The low 12 bits of CR3 are always 0 because the Page
Directory always starts on a page boundry. The 10-bit DIR value from
the Linear Address points to the needed Page Directory Entry.

2. The high 20 bits of the Page Directory Entry point to a Page
Table; 12 low-order zeros are tacked on to make a full physical
address for the page-aligned table. The 10-bit PAGE value from the
middle of the Linear Address points to the needed Page Table Entry.

3. The high 20 bits of the Page Table Entry point to a page frame; 12
low-order zeroes are tacked on to make a full linear address for the
page frame. The 12-bit OFFSET value from the low-order bits of the
Linear Address points to the needed location in memory.

Each page directory has up to 1024 entries, allowing that many page
tables. Each page table can point to as many as 1024 pages, each 4 Kb
long. This means that a single directory can address 1024 * 1024 *
4096 bytes, or 4 Gb (the entire physical address space of the 80386).

The Page Directory Entries (PDEs) and Page Table Entries (PTEs) are
almost identical. The page table can be thought of as a "page
descriptor table" and the Page Table Entry as a "page descriptor", if
this helps keep them straight. Figure 5-3 shows an entry like that
found in either table. A bit-by-bit breakdown is listed below.

1. PAGING ADDRESS (Bits 31...12). For a PDE this address points to a
Page Table; for a PTE it points to a page. The lower 12 bits of the
address are always 0's, since both Page Tables and pages are aligned
on 4096-byte boundries.

Bit
31 12 11...9 8 7 6 5 4 3 2 1 0
Paging Address OS Res 0 0 D A 0 0 U/S R/W P

Figure 5-3. Page Directory/Page Table Entry

2. OS RESERVED (Bits 11...9). These bits are available for operating
system use. A typical function would be keeping statistics for
virtual memory and page swapping, like the number of times a page has
been accessed in a given period.

3. D (Bit 6). This is the Dirty bit for page table entries, which is
set automatically when the page is written to.

4. A (Bit 5). This is the Accessed bit for page table and page
directory entries, which is set automatically when the page is read or
written to.

5. U/S (Bit 2). This is the User/Supervisor bit. If it's set then
programs with protection level 3 (lowest level) are allowed access.

6. R/W (Bit 1). If U/S is 1 (user access is allowed) then a zero in
this bit means only read accesses are allowed; a 1 means write
accesses are also allowed. {some detail snipped}

7. P (Bit 0). This is the Present bit that indicates whether the PDE
or PTE points to a page that is presently in memory. If this bit is 1
the bit fields are defined as above. If it's 0 the needed page is out
on disk and the remaining 31 bits can be the location of the page slot
out on disk that has the needed page."

The term "page slot" is defined earlier as: "The 4 Kb sections on disk
that hold pages are called page slots".

What I take home, after the above eye-glazing detail, is that 4k page
size is something fairly deeply built into the processor's hardware,
at least in the 386 generation, and not somthing whimsical that's
easily changed. I stopped following this level of processor detail
after the 486; as I recall, there wasn't anything in the 486 that
changed this, though there were a couple of extrra general-purpose
registers and a sprinkling of new instructions.

Win3.0 was written for 8088/8086 (Real Mode), 286 (Standard Mode) and
386 (386 Enhanced Mode). Real Mode was dropped in Win3.1, and
Standard Mode was dropped in WfW3.11 (it lives on as the
"mini-Windows" that runs as a Win95 installation GUI). NT peeled off
before Win95, and Win95 was written for 386.

I doubt whether any of the Win9x series (up to and including WinME)
changed the original swap file design at the level of page size,
especially as FAT32 typically uses 4k clusters.

It's possible the NT series may have changed this, somewhere on the
long journey from pre-Win95 NT to XP; if so, I'd guess this would have
been done for Win2000. But more likely it's the same, given that NTFS
has a hard preference for 4k clusters too.

>My arguements to the contrary start with how going from billionths of a
>second in memory to thousands of a second access time on a disk, the pagefile
>writes [memory to disk] are going to stack up while waiting for the disk to
>become available to be written to.

Yes, this is where the "wait" in swapping comes in. And yes; several
successive Moore's Law years should mean transistor space is cheap
enough to redo those 1024 x 1024 x 4096 figures to something grander,
but an "edge" like that can cause quite a ruckuss at the system
software level - a lot of stuff would have to be re-written.

>"thus transparent to what we are dealing with (transferring from RAM to HD)."

>The time spent transferring data/code from memory to disk IS revelvant when
>you consider that cluster size can make a huge difference to any file.
>Pagefile.sys is a file.

One avoids that by treating the swap file as a "special case", where
contiguity is assumed, thus avoiding trips to the FAT to see where
each next cluster is in the chain. Win3.1 introduced the "permanent"
swap file that worked in exactly this way, and one of the
optimizations of the day was to choose this for speed.

In Win95, this contiguous requirement seems to have fallen away, given
the OS can dynamically resize the swap file. I suspect what's
happened is that cluster run chains are managed internally somehow,
much as is the norm within NTFS. But that's a guess.

However, I don;t think everything stops when a page has to be pulled
from disk to RAM. More likely the OS shedulder passes control to the
next thread while the stalled one awaits its disk food.

>For example if you do video editing you do NOT want a 4kb cluster size.
>This is due to the fact you are working with relatively large files 1-2gigs
>and larger. Math shows you the reason. A 2gig file on 4kb clusters takes up
>500 clusters. A 2gig file on 512kb clusters takes up 4 clusters.

Er... did you mean 2M, there?

I think you will find the video editing app asserts itself to some
extent, in various ways, to work around file system issues. It's
likely to block data writes a number of clusters at a time, and (on
FAT32) break across files when the maximum size limit is reached.

But yes; while you don't want 512k clusters, you may indeed want
bigger clusters in such cases. The way you do that is through
partitioning, so that different things can benefit from different file
systems and cluster sizes. In this case, it's more likely the video
data will be on a different physical drive, to unlink the patterns of
head travel for system and data access.

>rarely is a file contigous and this is where the true "tire meets the road"
>consequences of fragmentation come in. 4 reads vs 500 reads makes the larger
>cluster size a faster retrieval option for large files.

True. Paging size is just one factor in performance, which is in turn
one factor in which file system and cluster size you choose. Because
priorities differ, I like 4k for C: but may prefer bigger elsewhere.

>So how is this data/code organized in the pagefile?

I have a feeling it may mirror the glimpse of what we saw about how
the processor itself managed page tables etc.

>Where does the cluster size of 4kb help in the disk read operation? The disk
>head could have read two 32kb blocks of data just as fast as thirtytwo 4kb
>blocks if they are configuous. Now there is a 64kb hole in the 384kb block
>of data. How is this space optimized for the next block of data to be
>written?

If you take the 4k size as imposed by the CPU - and speculation aside,
I see no reason to believe this has changed - then a 16k cluster size
means 4 x as many bytes have to trundle through the bus and into RAM
via DMA, with the excess thrown out if it's not needed (or extra
inventory tracking if it is to be used as "cache").

While DMA frees the CPU of gazing at each byte as it makes the trip,
it's still not quite a free lunch.

>The last point is that both Intel and MS documentation talk about large
>memory pages. The intel URLs talk about how programmers can use switches in
>their programming to utilize different memory models.

I'd worry about confusing memory segmentation, software's internal
overlay paging schemes, and the processor's virtual memory paging,
when considering what a "page" means.

>concerning XP in the section titled "Windows XP: Kernel Improvements", MS
>talks about XP's use of "large memory pages of 4meg". According to this
>article if you have more then 255megs of ram you are automatically going to
>use large memory pages.

Well, that's a URL I'd like to see. Maybe I can biopsy and Google it?

>quote from article
>"on such systems, these files (and other core operating system data such as
>initial nonpaged pool and the data structures that describe the state of each
>physical memory page) are mapped with 4MB "large pages" (as opposed to the
>normal 4KB page size on the x86 processor set). By mapping this core
>operating system code and data with 4MB pages"

Bingo!

http://msdn.microsoft.com/msdnmag/issues/01/12/xpkernel/default.aspx

"... these files (and other core operating system data such as initial
nonpaged pool and the data structures that describe the state of each
physical memory page) are mapped with 4MB "large pages" (as opposed to
the normal 4KB page size on the x86 processor set). By mapping this
core operating system code and data with 4MB pages, the first
reference to any byte within each 4MB region results in the x86 memory
management unit caching the address translation information to find
any other byte within the 4MB region without having to resort to
looking in page table data structures. This speeds address
translation."

Note that this large page size applies to some files only, not
everything, and that the article doesn't imply the processor's page
size has changed. It looks more like an added layer of abstraction
over an unchanged processor reality.

>The article does not talk about paging to disk at all.

Quite; it goes about locating offsets into large files without having
to check whether it's still in RAM. You'd prolly find the files
involved are locked into RAM anyway, i.e. not to be paged out.

>If the Intel processor supports the three memory management models, MS
>programming suppports large memory pages then how can it be assumed ALL
>memory manager operations are done in 4kb pages? Wouldn't the OS's memory
>manager stratagy change depending on the application being run? How do we go
>from 4kb pages in RAM to be equal to 4kb clusters on disk?

We're guessing at detail here. We can either take the recommendation
of the system guys at face value - and they do seem to show a
preference for 4k clusters - or we have to swot up to the point we can
meaningfully assess this stuff first-hand.

To be honest, it's more work than I can take on, right now ;-)

>---------- ----- ---- --- -- - - - -
   "He's such a character!"
   ' Yeah - CHAR(0) '
>---------- ----- ---- --- -- - - - -

Relevant Pages

  • Re: Cluster computing drawbacks
    ... >>>latency. ... > memory use -- access method be damned. ... almost all supercomputers ever built are clusters. ... > of a SMP's bus, the cluster essentially becomes a SMP. ...
    (comp.arch)
  • Re: Cluster computing drawbacks
    ... clusters are inferior to shared memory multiprocessors because they usually provide lower interconnect bandwidth and always provide *much* higher communication latency. ... almost all supercomputers ever built are clusters. ... The only exceptions might be the vector Crays, NEC, Fujitsu, and SMPs. ... Without the MPI overhead, the Altix's memory latency should be *significantly* less than 993 ns, by at least 2X. ...
    (comp.arch)
  • Re: combinations script - out of memory - optimization?
    ... a while ago i obtained a script that computes all unique subsets of a ... The script works fine when N<14, but past that value my server gives up ... of clusters. ... I am expressing it in Perl, and the "out of memory" phenomenon probably ...
    (comp.lang.perl.misc)
  • combinations script - out of memory - optimization?
    ... a while ago i obtained a script that computes all unique subsets of a ... The script works fine when N<14, but past that value my server gives up ... of clusters. ... I am expressing it in Perl, and the "out of memory" phenomenon probably ...
    (comp.lang.perl.misc)
  • Re: memory leak using system.windows.forms.timer
    ... To my own suprise the code bloated up the memory annyway an was not ... Dim adInfo As AppDomainAD = DirectCast), ... Using entry As New DirectoryServices.DirectoryEntry, mySearcher ...
    (microsoft.public.dotnet.languages.vb)