topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Wednesday December 11, 2024, 1:37 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Back to basics : virtual memory and page file ...  (Read 5774 times)

joiwind

  • Participant
  • Joined in 2009
  • *
  • Posts: 486
  • carpe momentum
    • View Profile
    • Donate to Member
Back to basics : virtual memory and page file ...
« on: June 15, 2011, 07:03 AM »
This is going back so far that I can't remember so much about this question, so I'm asking for someone's advice. I'm quite aware that it's probably a stupid question, but they're the best aren't they ...

I have virtual memory and page file set up on this PC and for some reason the virtual memory is hardly ever used whereas the page file of course is (see attached screen capture).
I have searched various sites about this and many seem to confuse the two, some even saying it's the same thing, i.e  virtual memory = page file.
So what I'm asking is : as the virtual memory never seems to be used to it's full extent, in fact far from it, should I reduce the size and if so how do I go about it ? The idea being to free up resources.
Thanks.

xp

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #1 on: June 15, 2011, 10:04 AM »
Why did you set up virtual memory if I may be so bold? :huh:

About the only time I've ever seen that is if some app (video/photo/music editor, etc) wants it's own swap (or buffer) space because it doesn't trust Windows and the swap file to provide it when it needs it - or to have enough contiguous free space for it when it does.

Photoshop was one app that always used to manage it's own memory. Don't know if it still does.
 :)



« Last Edit: June 15, 2011, 10:15 AM by 40hz »

joiwind

  • Participant
  • Joined in 2009
  • *
  • Posts: 486
  • carpe momentum
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #2 on: June 15, 2011, 10:30 AM »
Can't remember ...  :-[

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #3 on: June 15, 2011, 10:54 AM »
I suspected that might be the case.  ;D (Don't you just hate it when you've set something up but can no longer remember why or what for? Happens to me all the time.)

I suppose you could try removing it to see what breaks. But for 51Mb in disk space savings, it hardly seems worth messing with.
 :)


joiwind

  • Participant
  • Joined in 2009
  • *
  • Posts: 486
  • carpe momentum
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #4 on: June 15, 2011, 12:11 PM »
I suppose you could try removing it to see what breaks. But for 51Mb in disk space savings, it hardly seems worth messing with.

Yes true, but (as per the screen capture) aren't the 2047 mbs allocated and unusable for anything else or is this just my ignorance showing through again ...?  ;)

Thanks 40hz.

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #5 on: June 15, 2011, 02:08 PM »
Scuze me. Head up my butt. Ignore what used to be here. I was thinking of a RAM disk which is totally wrong.
:)

------------------------------------------

OK. I'm forgetting my basics. Rather than rewrite it, let's let Microsoft explain (with some emphasis added):

In most modern operating systems, including Windows, application programs and many system processes always reference memory using virtual memory addresses which are automatically translated to real (RAM) addresses by the hardware.  Only core parts of the operating system kernel bypass this address translation and use real memory addresses directly.  The virtual memory management component of the operating system maintains the tables used by the hardware to provide the mapping of virtual addresses into real addresses.  A small amount of RAM is used by those parts of the operating system that can not be paged out (for example, the virtual memory manager) and is thus not available for assignment to virtual memory.

The key point here is that Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.

Why it's a good thing and you want it:

There are several advantages to Virtual Memory implementations with per process virtual address spaces, some of which are:

- Application writing is simplified.  The application developer doesn’t have to worry about how much RAM is available or what addresses are available to it.  The application writer (and compiler) knows that every application will get its own set of virtual addresses (called an Address Space) that it can use any way it wishes (except for the portion of the address space reserved by the operating system) without regard to what other applications are doing.

- The system is more robust and secure because applications can not overwrite or read memory belonging to another application – there is no addressability to another application’s address space.

- Management of RAM allocation to processes is centralized in a core part of the OS.  The algorithms used by the Virtual Memory management part of the OS have a long history, are well understood, quite sophisticated and highly optimized.  The knowledge and skills required to do this well are very specialized and not usually present in application developers whose focus is on the application/business requirements.

So what is it that's using it - and why is it 2GB in size:

A process is essentially, the combination of:
  • Some executable code
  • A virtual address space
  • One or more threads of execution.

The only way to increase the size of the virtual address space for a process beyond 4 GB is to use 64 bit hardware with a 64 bit version of the operating system and application built for the 64 bit instruction set.

The nub of it is, that no matter how much physical RAM is in the computer, the amount of memory available in the process’ private part of the virtual address space in 32 bit Windows implementations is limited to:
2 GB
- without the /3GB switch - this is the normal, default maximum private virtual address space

So it's not something you set up like you would the pagefile size. It's controlled by Windows itself.

Sorry for the earlier confusion on my part. :-[

« Last Edit: June 15, 2011, 02:49 PM by 40hz »

joiwind

  • Participant
  • Joined in 2009
  • *
  • Posts: 486
  • carpe momentum
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #6 on: June 15, 2011, 02:43 PM »
Errmm ... yes, maybe, but I still don't know what's best to do - or how to do it ... :D

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #7 on: June 15, 2011, 02:47 PM »
Ignore it. It's out of your hands.  ;D :Thmbsup:


joiwind

  • Participant
  • Joined in 2009
  • *
  • Posts: 486
  • carpe momentum
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #8 on: June 15, 2011, 02:58 PM »
Oh no ! ... don't tell me someone else is controlling my computer ... ?  :o

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: Back to basics : virtual memory and page file ...
« Reply #9 on: June 15, 2011, 03:01 PM »
Not someone else - everyone else.  :tellme: