"Rod Speed" <rod.speed.aaa@gmail.com> wrote...
The only "odd" thing is your "we". Though you may be blind to reality, that
is not the case with most posters here.

Robert Heiling <robheil@comcast.net> wrote
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 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.

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.

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.

John Weiss <jrweiss98155nospamatnospamcomcastdotnospamnet> wrote
We'll see...

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.

Rod Speed wrote:
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.

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

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."?

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.

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

Robert Heiling <robheil@comcast.net> wrote
Thats overstating it, the page file doesnt get big enough
for everything thats in physical ram in that situation.

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

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.

Yes, and it got dropped from the selective quoting.

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.

It didnt.

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.

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

Robert Heiling <robheil@comcast.net> wrote
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.

Even you cant actually be THAT thick.

Robert Heiling <robheil@comcast.net> wrote:

lol

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

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. Duh! Why didn't I
think of that?

Bob

On Sun, 11 Mar 2007 14:45:02 GMT, Joe S <js@foldback.net>
wrote:

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).

On Mon, 12 Mar 2007 08:00:04 +1100, "Rod Speed"
<rod.speed.aaa@gmail.com> wrote:


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

kony <spam@spam.com> wrote
You never ever have, you pathetic excuse for a lying bullshit artist.

On Sun, 11 Mar 2007 14:40:35 GMT, Joe S <js@foldback.net>
wrote:


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


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.

kony <spam@spam.com> wrote
Its true even if we dont.

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

On Sun, 11 Mar 2007 20:37:00 +1100, "Rod Speed"
<rod.speed.aaa@gmail.com> wrote:

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.


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.

kony <spam@spam.com> wrote
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.

kony <spam@spam.com> wrote
Yep.

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

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

We'll see...

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

On Mon, 12 Mar 2007 14:43:13 +1100, "Rod Speed"
<rod.speed.aaa@gmail.com> wrote:



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.

On Mon, 12 Mar 2007 15:30:35 +1100, "Rod Speed"
<rod.speed.aaa@gmail.com> wrote:


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.

On Mon, 12 Mar 2007 15:33:42 +1100, "Rod Speed"
<rod.speed.aaa@gmail.com> wrote:



Rod is trolling


Ok then

kony <spam@spam.com> wrote
Yep.

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.

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