Location of system and cache partitions

[John Weiss]

How odd that we aint seen even a single substantiation from you, ever.

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

 

[Rod Speed]

Rod Speed wrote

Are you certain that won't be paged, even though a copy remains in ram?

I in fact said that Win does in fact put stuff in the page file even when
there is plenty of free physical ram, AND leaves it in physical ram,
and it does that in the background, essentially because its never going
to be possible to predict what some app will want physical ram wise
or what the user will choose to run, so you might as well put the best
candidates for the page file in the page file ahead of time, in the
background, so you can just mark that stuff as no longer in physical
ram if there become a need for more physical ram than is installed.
That is done essentially instantly when its already in the page file.

What puzzles me most about this whole discussion is the lack of mention
of the demand that the running tasks place on memory requirements.

What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

Only the user can ever know that, the OS can never be sure what some
app will request, or what the user may choose to run for the first time etc.

So it makes sense to put some stuff in the page file in the background,
just in case more physical ram is needed than is actually installed.

Yes. The size of physical ram is less important than the total memory
required by the running tasks for program code and data space. That
figure plays the most important role in the size of the pagefile and
its role has not even been mentioned.

Because what was being discussed was what Win does page file use wise
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

That is obviously going to vary depending upon what use is made of the
systems and which, and how many, applications are being run concurrently.

Duh. Pity that was assumed when we were discussing the use of the page file
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

 

[Rod Speed]

The only "odd" thing is your "we".

We'll see...

Though you may be blind to reality, that is not the case with most posters here.

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

Have fun listing a single example of you ever substantiating a damned thing, ever.

 

[Robert Heiling]

I in fact said that Win does in fact put stuff in the page file even when
there is plenty of free physical ram, AND leaves it in physical ram,
and it does that in the background, essentially because its never going
to be possible to predict what some app will want physical ram wise
or what the user will choose to run, so you might as well put the best
candidates for the page file in the page file ahead of time, in the
background, so you can just mark that stuff as no longer in physical
ram if there become a need for more physical ram than is installed.
That is done essentially instantly when its already in the page file.

Right. What you state there is my understanding also. Win pages everything that
is pageable. I thought I was in agreement with you all along.

What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

If you say so. That's not readily apparent from the rhetoric.

Only the user can ever know that, the OS can never be sure what some
app will request, or what the user may choose to run for the first time etc.

So it makes sense to put some stuff in the page file in the background,
just in case more physical ram is needed than is actually installed.

Ok, It got mentioned there. Is that what you meant by:
"What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE."?

Because what was being discussed was what Win does page file use wise
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

That was a couple of messages ago that was said. There was also discussion of
which HD to put it on and which IDE etc. I didn't realize the discussion had
narrowed like that.

Duh. Pity that was assumed when we were discussing the use of the page file
WHEN THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE.

Whatever! The point is that the size of ram is irrelevant. You need a pagefile
that is large enough to hold the maximum code & data that your applications
requires.

Bob

 

[Rod Speed]

Rod Speed wrote

Right. What you state there is my understanding also.

Win pages everything that is pageable.

Thats overstating it, the page file doesnt get big enough
for everything thats in physical ram in that situation.

I thought I was in agreement with you all along.

If you say so. That's not readily apparent from the rhetoric.

Its more that it got rather lost in the selective quoting.

Ok, It got mentioned there. Is that what you meant by:
"What was being discussed was what Win does page file use wise WHEN
THERE IS ENOUGH PHYSICAL RAM TO NEVER NEED THE PAGE FILE."?

More my original,

With 20/20 hindsight, thats said a bit cryptically with the bit after the 'due to'
I should have made it clearer that I meant that Win still uses the page file
in that situation, but I did say elsewhere that since it only uses it in the
background in that situation, the location of it makes no difference,
because that only happens in the background in that situation.

That was a couple of messages ago that was said.

Yes, and it got dropped from the selective quoting.

There was also discussion of which HD to put it on and which IDE etc.

Yes, but that use by Win of the swap file in that situation where there
is still plenty of free physical ram is relevant to the location of the page
file, because in THAT situation the location of the page file doesnt matter.

I didn't realize the discussion had narrowed like that.

It didnt.

Whatever! The point is that the size of ram is irrelevant.

No it isnt when the location of the page file is being discussed. If you dont
have enough physical ram, the page file will be used when other stuff is
going on, and THEN the location of the page file CAN make a difference.

You need a pagefile that is large enough to hold the
maximum code & data that your applications requires.

Thats always been obvious. What was being discussed was WHEN
THE LOCATION OF THE PAGE FILE CAN MAKE A DIFFERENCE.

 

[Rod Speed]

Rod Speed wrote

And summarizing, the answer given appears to be that the location
of the pagefile can make a difference if the pagefile gets used.

No it doesnt. WHEN THE PAGE FILE IS ONLY USED BY WIN WHEN
THERE IS PLENTY OF FREE PHYSICAL RAM, AND THAT IS DONE
IN THE BACKGROUND, SO THAT STUFF DOESNT NEED TO BE
MOVED TO THE PAGE FILE WHEN THERE ISNT ENOUGH PHYSICAL
RAM, THE LOCATION OF THE PAGE FILE *THEN* DOESNT MATTER.

Duh! Why didn't I think of that?

Even you cant actually be THAT thick.

 

[John Doe]

And summarizing, the answer given appears to be that the location
of the pagefile can make a difference if the pagefile gets used.
Duh! Why didn't I think of that?

Bob

lol

"The road is long, with many a winding turn... la la la"

 

[Robert Heiling]

Thats always been obvious. What was being discussed was WHEN
THE LOCATION OF THE PAGE FILE CAN MAKE A DIFFERENCE.

And summarizing, the answer given appears to be that the location of the
pagefile can make a difference if the pagefile gets used. Duh! Why didn't I
think of that?

Bob

 

[kony]

See "Virtual Memory in Windows XP" http://aumha.org/win5/a/xpvm.htm
A snippet (see the link for full context) says:

"For any given workload, the total need for virtual addresses will
not depend on the size of RAM alone. It will be met by the sum of RAM
and the page file. Therefore in a machine with small RAM, the extra
amount represented by page file will need to be larger, not smaller,
than that needed in a machine with big RAM." etc etc etc.

That is true if we consider the jobs the system is running
to be a fixed variable. We often don't - often if a system
isn't running huge jobs, there is no money (wasted?) put
into massive amounts of memory for it, so when a system is
configured per job and has a lot of memory, that is
typically an indicatio of the potential to need more virtual
memory space too (but even this will vary depending on exact
jobs and the way the app decides how large a space to
reserve for it's use).

 

[kony]

How odd that we aint seen even a single substantiation from you, ever.

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

 

[Rod Speed]

Seems like even if someone provides substantiation,

You never ever have, you pathetic excuse for a lying bullshit artist.

 

[kony]

I am the OP.

Can you prove that beyond a shadow of a doubt? Now that
Rod's involved we can't trust much of anything. ;-)

Way back in the original post it says I run XP.

The generic answer is to put your pagefile on the most used
partition of the least used, *modern performance level*,
drive. Put that drive on the PATA controller channel that
is least used simultaneous to any other I/O that might be
occuring while the system is actively making use (reading or
writing) of virtual memory.

 

[Rod Speed]

That is true if we consider the jobs the system is running to be a fixed variable.

Its true even if we dont.

We often don't - often if a system isn't running huge jobs, there is no money
(wasted?) put into massive amounts of memory for it, so when a system is
configured per job and has a lot of memory, that is typically an indicatio of
the potential to need more virtual memory space too (but even this will vary
depending on exact jobs and the way the app decides how large a space to
reserve for it's use).

Meaningless waffle and irrelevant to what is being discussed, the location
of the page file and the situations where the LOCATION matters.

 

[kony]

Wrong, as always. The answer can obviously
cover all the possibilitys and so be complete.

Nope, trying to divide access between drives and channels is
offset by the performance difference between all drives.
You can get better performance from two new 400GB drives on
the same channel than one 400GB on channel 0 and one 40GB on
channel 2, for example.

Hardly ever in practice.

Almost always in practice. Seldom does one buy a boatload
of identical PATA drives then later reconfigure them all on
the same system, unless that system is just a filestore
instead of actively used XP PC.

 

[Rod Speed]

Can you prove that beyond a shadow of a doubt?
Now that Rod's involved we can't trust much of anything. ;-)

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

The generic answer is to put your pagefile on the most used
partition of the least used, *modern performance level*,
drive. Put that drive on the PATA controller channel that
is least used simultaneous to any other I/O that might be
occuring while the system is actively making use (reading or
writing) of virtual memory.

The real generic answer is to ensure you have enough physical ram
so the page file isnt used because there isnt enough physical ram.

THAT provides a VASTLY better performance config.

 

[Rod Speed]

Yep.

trying to divide access between drives and channels is
offset by the performance difference between all drives.

And that can be spelt out in the complete answer, you pathetic excuse for a bullshit artist.

You can get better performance from two new 400GB drives on the same
channel than one 400GB on channel 0 and one 40GB on channel 2, for example.

And that can be spelt out in the complete answer, you pathetic excuse for a bullshit artist.

Almost always in practice.

We'll see...

Seldom does one buy a boatload of identical PATA drives
then later reconfigure them all on the same system, unless
that system is just a filestore instead of actively used XP PC.

Irrelevant to the last bit of your mindless waffle that I said hardly ever happens in practice.

 

[kony]

Its true even if we dont.

Nope, otherwise one expects a system that runs larger jobs
to have been properly equipped for these tasks. Since size
of job obviously effects amount of real and virtual memory
used, it would have to be a fixed variable or else "it
depends" on that variable.

 

[kony]

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



The real generic answer is to ensure you have enough physical ram
so the page file isnt used because there isnt enough physical ram.

THAT provides a VASTLY better performance config.

Duh? It would seem obvious enough to have ample system
memory, but that won't keep the system from accessing the
pagefile either to some extent so long as it's enabled at
all, so there is still a minor penalty.

Yes we can see the pagefile is not only accessed during idle
time. Have you ever bothered to look for any system
monitoring tools that monitor this? I'm not going to do
your work for you.

 

[kony]

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



Rod is trolling

Yep.

Ok then

 

[Rod Speed]

Yep.

otherwise one expects a system that runs larger jobs
to have been properly equipped for these tasks.

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.

And that doesnt necessarily impose much of a performance penalty
either, most obviously when the system keeps a number of larger
apps loaded for convenient switching between them, but where
they arent all running and consuming cpu resources all the time.

Since size of job obviously effects amount of real and virtual memory used,
it would have to be a fixed variable or else "it depends" on that variable.

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