PCBUILD Archives

Personal Computer Hardware discussion List

PCBUILD@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Gillett <[log in to unmask]>
Reply To:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Date:
Mon, 19 Oct 1998 10:32:27 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (125 lines)
On 17 Oct 98 at 8:18, John Chin wrote:

> At 11:32 AM 10/16/1998 David Gillett wrote:
> >On 16 Oct 98 I wrote:
> >> The best solution is:  Bring your RAM up to at least 64MB and let
> >> Windows 98 handle your Swap File. This amount of RAM will
> >> substantially reduce the Windows need for virtual memory and avoid
> >> the attendant, time wasting Swap File management.
> >
> >  I beg to respectfully disagree.  While installing more RAM will
> >reduce Windows' USE of the swap file, it won't affect Windows'
> >MANAGEMENT of the swap file at all. . . .
> >
> >  Specifically, swap file space is allocated because a program uses
> >RAM, not because there's not enough real RAM for it.  Adding RAM will
> >reduce the number of reads and writes of the swap file, but it won't
> >affect its growth and shrinkage.  A swap file managed by Windows WILL
> >become fragmented, if there is any other activity on that volume.
>
>
> David:
>
> Let's reason this out.
>
> Programs make calls for memory at an address mapped to a location
> on the page table. That location on the page table then maps to either
> physical RAM or to a swap file. Memory in Windows 95 programs is
> broken down into 4K pages. These data pages are what is being
> mapped between the virtual addresses and virtual memory. When a
> program makes a call for a data page that is not in RAM, a page fault
> occurs. The page fault tells the VMM to load that page from the swap file
> into memory. When a system has a page fault, it reading information
> from the hard disk rather than memory.
>
> Thrashing occurs when you experience excessive page faults, and this
> is manifested by high CPU utilization and large amounts of hard disk
> activity. Page faulting is alleviated by adding more RAM or running
> fewer applications.
>
> Moreover, demand paging occurs when RAM becomes full and swaps
> to disk.

  All agreed.

> It is demand paging that mostly makes Windows adjust the swap
> file (to grow and shrink) as needed.

  Negatory, good buddy.

  Because Win16 swapped *segments*, of variable size, swap file
space was only allocated when a segment needed to be swapped out, as
you describe.  THAT IS NOT HOW WIN32 DOES IT.
  When an application is launched, a virtual memory map is created
for it.  Code and constant data pages are "backed" by chunks of .EXE
or .DLL file, and page faults to these addresses will be served by
reloading the page from there.  Heap and stack space is backed by
space in the swap file; THIS FILE SPACE IS PRE-ALLOCATED WHEN THE
HEAP/STACK RAM SPACE IS ALLOCATED.  If/when the application needs to
swap such space to disk, the swap file pages already allocated for
this purpose will be used.
  Win32 does this because it moves the swapfile space allocation code
out of the page-fault handler.  It *can* do it, because it's working
in pages rather than segments -- each time an application asks for
another page of RAM, a page of swap file is allocated for it.
  [Yes, this means that the swap file can become fragmented
internally.  This isn't *generally* a problem.  (Under at least the
first version of Win95, closing a large application could trigger an
"internal defrag" of the swap file, in order to shrink it, freezing
the machine for 10 seconds or more while the drive ground furiously.
The advice to NOT let Windows manage the swap file dates from this
time, and it's possible that more recent versions of Win 9x treat
this scenario a little differently.)]
  [It's my belief that popular misunderstanding of this behaviour has
contributed to (but not been the sole factor in!) Win 9x's reputation
as a "memory hog".]

  [I think I recall this being explained in great depth in Jeffrey
Richter's "Advanced Windows".  The book is for experienced Windows
software developers, and so I don't recommend that everyone who reads
this list rush out and buy it....]

> Fragmentation is avoided when where are fewer writes to the swap file,
> and with fewer additions and deletions (because we have installed lots
> of RAM), there is less need for Windows to compress and resize, and
> therefore there is less management.

  Fragmentation, occurs when the swap file grows and shrinks.  Under
Win32, this happens as applications request and release RAM, not as
they get written to the swap file.

> With 128MB of RAM, one could conceivably DISABLE virtual memory
> (if one did not use Internet Explorer, Photoshop, Office and Pagemaker
> simultaneously). However, that is still fairly risky. So I prefer to leave
> a swap file. I still have a permanent swap file on G: drive but it appears
> hardly used because of all the RAM. So I let Windows handle it.

  Agreed.  If you have enough RAM to eliminate swapping, you can
eliminate swap file growth/shrinkage by also taking this step --
which I don't generally recommend either.

> Finally, if you delete the swap file at every shut down (exit to DOS) or at
> every boot up (F8 -- Command Prompt), it will be reconstructed at
> Windows Startup, and will be nice and clean and unfragmented. Of
> course, some people run their systems 24 hours and hardly ever reboot,
> unless the memory holes get too large. These people should delete the
> swap file at the Command Prompt occasionally, or run Norton which
> can defrag a swap file (Windows 95 Defrag cannot).

  Oops, this isn't quite true, either.  The procedure you suggest
*can* produce a contiguous swap file if enough of the free space on
the volume is already contiguous.  If you have plenty of space to
spare, and defrag the volume regularly, it may be reasonable to
assume this.
  The only way to be *sure* that a swap file will get created
contiguously, though, is if it is being created on an empty volume,
or one that has been defragged since the old swap file was deleted
(and has had no other files created/deleted since the defrag).
Putting the sap file on its own volume is an easy way to ensure this.

David G

                                  -----
                PCBUILD mailing list -  http://nospin.com
         Bob Wright:[log in to unmask] - Drew Dunn:[log in to unmask]

ATOM RSS1 RSS2