Location of system and cache partitions

[Rod Speed]

Duh? It would seem obvious enough to have ample system memory,

And that is obviously the generic answer that satisfys
all configs that the OP didnt spell out in detail.

but that won't keep the system from accessing the pagefile
either to some extent so long as it's enabled at all,

No one ever said it did.

so there is still a minor penalty.

NOT when what pagefile activity that does still occur ONLY
happens in the background when nothing else is needing those
resources, in case there does turn out to be a need to more
physical ram than the system has installed, even when there
is still plenty of physical ram still unused.

Yes we can see the pagefile is not only accessed during idle time.

No we cant. I told you how to prove that and you never did bother to check it that way.

Have you ever bothered to look for any
system monitoring tools that monitor this?

Corse I have.

I'm not going to do your work for you.

Never ever could bullshit its way out of a wet paper bag.

You've never produced a shred of substantiation for your stupid
pig ignorant claim that Win uses the page file when the resources
are being used when there is plenty of free physical ram.

 

[Rod Speed]

On Mon, 12 Mar 2007 15:33:42 +1100, "Rod Speed"



Rod is trolling



Ok then

Thanks for running up the white flag, child.

 

[John Weiss]

The whole point of a page file is to handle the situation where
there is a need for more physical ram than the system actually has.

That may have been the original idea, but actual implementation has been
corrupted way beyond that simplicity. As has been pointed out by several
people here already, Windows uses the pagefile even when there is plenty of
physical RAM for all current needs.

 

[John Weiss]

No we cant. I told you how to prove that and you never did bother to check
it that way.

Corse I have.

Then you haven't looked very hard...

You've never produced a shred of substantiation for your stupid
pig ignorant claim that Win uses the page file when the resources
are being used when there is plenty of free physical ram.

I am watching the Task Manager Performance page and can see the PF usage
change dynamically while working on something else. I can also watch the
Processes page and monitor what process is accessing the PF.

All this is happening with 2 GB RAM installed and over 1.2 GB free, and over
500 MB of pagefile in use!

 

[Rod Speed]

That may have been the original idea,

Its STILL the whole point of a page file.

but actual implementation has been corrupted way beyond that simplicity.

Nope, ALL that has changed is the realisation that it makes sense to
put what would be moved into the page file when there isnt enough
physical ram, into the page file ahead of time, using idle resources,
so that if there is a need for more physical ram than there is installed,
all that needs to happen is to reuse the physical ram thats been written
to the page file. You dont have to wait while that stuff is written to the
page file before the physical ram can be reused, its already in the page file.

As has been pointed out by several people here already, Windows uses the pagefile even when there
is plenty of physical RAM for all current needs.

And by me too. What is being missed completely by the pig ignorant is that
Windows does that BEFORE there is no more physical ram left, IN CASE
there is a need for more physical ram than is installed, instead of waiting
till there is no physical ram free before doing that. When that is done using
idle resources, there is NO downside with doing that and in fact it speeds
things up because you dont need to write that stuff to the page file WHEN
there is no more physical ram free, with the delay that is inevitable if you
leave writing to the page file till the last minute.

Its a VERY simple concept and fools like you cant even manage to grasp it.

 

[Rod Speed]

Then you haven't looked very hard...

Easy to claim.

Pity you havent even managed to grasp the reason Windows
uses the page file when there is still plenty of free physical ram.

I am watching the Task Manager Performance page and can see the PF usage change dynamically while
working on something else.

Doesnt prove a damned thing about whether that is happening with free resources.

I can also watch the Processes page and monitor what process is accessing the PF.

Doesnt prove a damned thing about whether that is happening with free resources.

All this is happening with 2 GB RAM installed and over 1.2 GB free, and over 500 MB of pagefile in
use!

Doesnt prove a damned thing about whether that is happening with free resources!!!

 

[JAD]

That may have been the original idea, but actual implementation has been corrupted way
beyond that simplicity. As has been pointed out by several people here already, Windows
uses the pagefile even when there is plenty of physical RAM for all current needs.

yeah its been a problem here...
2 gigs of ram
system managed virtual
2 X 1.9gigs swapfiles - 1 on each drive
I changed it to min 256 max 1024
all is well with PhotoShop and Illustrator (which were always the first to complain)
so far it has never gotten any bigger than the minimum

 

[kony]

That may have been the original idea, but actual implementation has been
corrupted way beyond that simplicity. As has been pointed out by several
people here already, Windows uses the pagefile even when there is plenty of
physical RAM for all current needs.

Yes, but a fair percent of that is just allocation, not
actual use of the drive for paging data. You will still
have less paging with (enough) memory in the system.

 

[kony]

Doesnt prove a damned thing about whether that is happening with free resources!!!

Of course it does, unless you thought he had ~ 800MB of
memory used for the OS alone... otherwise there's a lot of
UNfree resources contending for system time and drive
access.

 

[Rod Speed]

Of course it does,

Of course it doesnt.

unless you thought he had ~ 800MB of memory used for the OS alone...

Irrelevant to whether that use of the page file that he
can see is BEING DONE USING FREE RESOURCES.

otherwise there's a lot of UNfree resources contending for system time and drive access.

Thanks for that completely superfluous proof that you have
never ever had a ****ing clue about anything at all, ever.

 

[kony]

Irrelevant to whether that use of the page file that he
can see is BEING DONE USING FREE RESOURCES.

If that's "free resources" then we can as easily argue that
every single thing windows or an app is doing is merely
using "free resources". Use of a bit of CPU time, memory
access, drive controller and drive. Just like having two
apps trying to run alongside each other. You can't *defer*
virtual memory, the whole point of it is that it's actively
happening as needed, but the "need" is a dumb logic that is
too conservative for well endowed systems, depending on how
the amount of physical memory compares to the requirements
of the jobs that system runs. To be most efficient there
would need be a user-selectable or learning profile and a
use pattern that remains fairly static - something we can't
necessarily assume on a PC.

If you're trying to say that windows waits till the system
utilization is low, that's about the last time there was a
need to free up memory, but by paging anything out it
creates the opportunity for the next use session to require
that paged data read back again when it was most important
for it to not be paged out. It can help to page out unused
data ahead of time, but it is done too aggressively within
the assumption it is a good thing to do when it is too often
just a wasted effort, and as mentioned above, then has to be
read back into physical memory because it can't predict the
future without a crystal ball.

What really happens is that applications allocate more
memory than they use, and the pagefile utilization figures
reflect this allocated (but often remaining unused) virtual
memory space. It is not likely that John's system (as an
example since he reported a figure) is actually paging out
most of that 500MB as data rather than just reserved,
allocated virtual space, but nevertheless there is pagefile
access ongoing, it is still a minor performance hit relative
to not having it happen. The question is really whether the
penalty is worse that the potential that having no paging
allocation would result in out of memory errors, something
that depends entirely on the actual uses of the system.
Some people can turn off their swapfile and run like that,
and others will do something mundane like loading a game,
only to find an error generated about 15 minutes into
gameplay (which I have done, the system had ample free
physical memory but windows wanted to allocate more and
doesn't like not being able to do what it wants, regardless
of lacking a real need).

It is slower than not doing it, as it does happen during
NON-idle times, right in the middle of heavy use. It
certainly did when it generated the errors during the
gaming. After investigation I did re-enable the pagefile on
the system exhibiting the problem to confirm this account.

 

[Rod Speed]

If that's "free resources" then we can as easily argue that every single
thing windows or an app is doing is merely using "free resources".

Mindlessly silly. Win is putting stuff in the page file
and still leaving it in physical ram with resources which
are not being used by the apps or the OS, stupid.

Even you cant actually be THAT stupid, you're clearly
desperately attempting to bullshit your way out of your
predicament and fooling absolutely no one at all, as always.

If you're trying to say that windows waits till the system utilization is low,

Succeeding in saying, actually.

that's about the last time there was a need to free up memory,

With the use of the page file when there is still plenty of free physical
ram, IT AINT ABOUT A NEED TO FREE UP MEMORY, ITS ABOUT
WRITING WHAT WILL BE PUT INTO THE PAGE FILE AHEAD OF
TIME AND LEAVING IT IN PHYSICAL RAM SO THAT IF THERE
BECOMES A NEED FOR MORE FREE PHYSICAL RAM, THAT
STUFF IS ALREADY IN THE PAGE FILE AND THERE WILL BE
NO DELAY WHILE ITS WRITTEN TO THE PAGE FILE.

but by paging anything out it creates the opportunity for the
next use session to require that paged data read back again
when it was most important for it to not be paged out.

WHEN ITS WRITTEN THE PAGE FILE AHEAD OF TIME AND
LEFT IN PHYSICAL RAM SO THAT IF THERE BECOMES A
NEED FOR MORE FREE PHYSICAL RAM, THAT STUFF IS
ALREADY IN THE PAGE FILE AND THERE WILL BE
NO DELAY WHILE ITS WRITTEN TO THE PAGE FILE.

It can help to page out unused data ahead of time,

Corse it can and thats the reason for that page
file activity when there is still free physical ram.

but it is done too aggressively

It cant be done too aggressively IF ITS DONE WITH FREE RESOURCES.

within the assumption it is a good thing to
do when it is too often just a wasted effort,

Doesnt matter IF ITS DONE WITH FREE RESOURCES.

and as mentioned above, then has to be read back into physical memory

NO IT DOESNT IF ITS WRITTEN TO THE PAGE
FILE BUT IS KEPT IN PHYSICAL MEMORY TOO.

If there becomes a need for more free physical ram later,
ITS ALREADY IN THE PAGE FILE AND THAT AREA OF
PHYSICAL RAM CAN BE REUSED IMMEDIATELY BECAUSE
ITS ALREADY BEEN WRITTEN TO THE PAGE FILE.

because it can't predict the future without a crystal ball.

Dont need any crystal ball. IF there becomes a need for
more free physical ram, the physical ram being used by
the stuff thats been written to the page file incase there
becomes a need for physical ram can just be used without
any wait while its written to the page file.

Thanks for that completely superfluous proof that you
cant even manage to grasp even the simplest concepts.

What really happens is that applications allocate more memory
than they use, and the pagefile utilization figures reflect this
allocated (but often remaining unused) virtual memory space.

Thats an entirely separate issue to what is being discussed,
what is WRITTEN to the page file AND LEFT IN PHYSICAL
RAM, so that if there becomes a need for more physical
ram that stuff is already in the page file and the physical
ram is instantly available, because its been written to the
page file already.

<reams of your shit thats completely irrelevant to
what is being discussed flushed where it belongs>

 

[The Rod That Failed]

Seems like even if someone provides substantiation, they just get some
clown-wet-bag-something-or-other reply so it's a wasted effort.

Yeah, it was pretty funny when Rod had his ass nailed to the wall on the
"will the drive spin up is reset is asserted" issue. Thoroughly defeated
and humiliated, all Roddles could do was run away with his tail between
legs while claiming the OTHER guy was doing what Rod was in fact doing -
trying to bullshit his way out of his predicament.

 

[The Rod That Failed]

The only "odd" thing is your "we". Though you may be blind to reality, that
is not the case with most posters here.

You are arguing not only with a troll, not  only with a kook, but with the
epitome of mental illness and testimony to what some lucky Australian
Mental Health workers have to go through on a routine basis.

Trying not to admit defeat after being wrong for the umpteenth consecutive
time is making the fruitcake writhe around in his straight jacket as he
furiously strikes at the keys with the pencil in his mouth - frequently
pausing to fling away the drool and occasionally stopping to bang his
helmeted head against the wall to relieve some of the frustration.

 

[Rod Speed]

Some gutless ****wit desperately cowering behind
The Rod That Failed <[email protected]> desperately
attempted to bullshit its way out of its predicament and
fooled absolutely no one at all, as always.

 

[Rod Speed]

Some gutless ****wit desperately cowering behind
The Rod That Failed <[email protected]> desperately
attempted to bullshit its way out of its predicament and
fooled absolutely no one at all, as always.

 

[kony]

Mindlessly silly.

Why would we expect you to agree Rod? You're on a roll
recently.

Of course it would reduce the delay to write something to
the pagefile, but not if the system is doing this writing
while it has so much free memory still. It's not just
waiting till there is some arbitrary free/idle time, it
can't work that way because that's not when the virtual
memory is needed - and it can't accurately preidict
everything that might be done with the system so as to page
it all out ahead of time, there's still access ongoing and
that while there is still free physical memory.

 

[Rod Speed]

Why would we expect you to agree Rod? You're on a roll recently.

Yep, done you like a ****ing dinner, time after time after time, child.

Of course it would reduce the delay to write something to the pagefile,

Its FINALLY actually dawned on this fool what is being discussed.

but not if the system is doing this writing while it has so much free memory still.

Wrong, as always. The time to do it is when there are free
resources, because there may not be free resources later
if there becomes a need for more free physical ram later.

It's not just waiting till there is some arbitrary free/idle time, it can't
work that way because that's not when the virtual memory is needed

ITS DONE AHEAD OF TIME SO THAT THERE IS NO DELAY WHEN THERE
TURNS OUT TO BE A LATER NEED FOR MORE FREE PHYSICAL RAM.

- and it can't accurately preidict everything that might be
done with the system so as to pageit all out ahead of time,

DOESNT MATTER IF IT DOESNT ALWAYS GET THAT RIGHT WHEN
WRITING THAT STUFF TO THE PAGE FILE IS DONE WITH FREE
RESOURCES. THATS ALWAYS GOING TO BE BETTER THAN NOT
WRITING ANYTHING TO THE PAGE FILE IN CASE IT NEEDS TO
BE IN THE PAGE FILE LATER.

there's still access ongoing

You dont know that.

and that while there is still free physical memory.

Pathetic.

Thanks for that completely superflous proof that you have
never ever had a ****ing clue about anything at all, ever.

The only viable approach for you now is to shut your stupid trap and hope
that those reading your shit forget your terminal stupiditys as quickly as possible.

 

[kony]

ITS DONE AHEAD OF TIME SO THAT THERE IS NO DELAY WHEN THERE
TURNS OUT TO BE A LATER NEED FOR MORE FREE PHYSICAL RAM.

Ok, let's suppost it does an OUTSTANDING job of that, and it
doesn't impact system use at all. However, the system still
had free memory, and that code is now NOT in memory.
What happens when the user finishes the task that causes the
allocations to drop the code frorm cache so it's only in the
pagefile, then goes back to doing what they were previously
which was using that code that is now in the pagefile?

They have to wait for it to be paged back in. If you think
that is not a performance loss you are mistaken and it
certainly isn't free resource related. There are two sides
to paging Rod, what goes out may come back in - otherwise it
was kinda wasteful for the app or OS to have ever read or
generated that code from the HDD (original file?) in the
first place, except as I wrote previously, there is no
crystal ball, it has to rely on a generic logic that is not
suited to all systems or uses, it was tailored to get
conservatively equipped systems running XP.

 

[John Weiss]

Of course it would reduce the delay to write something to
the pagefile, but not if the system is doing this writing
while it has so much free memory still. It's not just
waiting till there is some arbitrary free/idle time, it
can't work that way because that's not when the virtual
memory is needed - and it can't accurately preidict
everything that might be done with the system so as to page
it all out ahead of time, there's still access ongoing and
that while there is still free physical memory.

I just tried another simple experiment...

Open Explorer. Open the Processes window in Task Manager and activate the
VM column.

Access a folder or network drive with Explorer. Watch the VM usage
increase. Switch to another folder or drive. Watch it increase again.
Access the folder already accessed. Watch the VM usage increase yet again!

So, Windows is NOT simply reserving space for future usage; it is writing
data to the pagefile instead of physical RAM, and is apparently NOT reusing
that data! Neither is this being done "in the background" -- it is being
done at the time of access, by the foreground process!