Clayton Macleod wrote:
I think perhaps a refresher is warranted here, since you're forgetting
one basic fact, which is even mentioned in the article listed.
How many kernels have you built?
"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."
This statement bears no meaning on what I said. This rule is still for a
dynamic environment.
You should always have a pagefile, and it should be larger than your
installed RAM, even if you have tons of RAM and your memory usage
never nears your RAM limit. The people that wrote the memory manager
in the OS are telling you this, and you're thinking they don't know
what they're talking about?
Actually, the article was written by technical documentation staff.
There are plenty of videos from the Microsoft development labs regarding
their memory architectures and dynamic caching routines. I was fortunate
enough to study these in detail during the windows nt 4.0 days. Alot has
changed, but many of the basics of the NT kernel are the same. Several
MVP's have also published detailed documentation on this subject and
none agree with the above statement. This was the principle of 9X
paging, and is no longer required for a stable kernel (whereas it was
required to keep 9X stable in high memory conditions).
Besides, with HD space being well under
$1/GB there's no legitimate reason to complain about the "wasted" HD
space for a pagefile. Just set the minimum size
No, you misunderstand the reason - what is the data transfer rate of
your harddisk?
And your ram?
Now, next question, what is the speed of the bus that each of them is
attatched to? Frequency develops latency and switching rate develops
burst timings. Is the bus intelligent / managed? What about DMA? What's
the DMA penalty? Blah Blah Blah.
There is nothing wrong with the defaults - but the defaults are designed
for systems that can sometimes be run by home users rarely loading more
than internet explorer, who want blistering performance - in this case
alot of the static data and unused strings are loaded into the pagefile
- as they are rarely needed. When they are needed it is often the case
that processing is in flow for other operations (such as building part
of the gui) and the IDE latency rarely causes issue. As such the choice
of data page here provided more free memory for new applications, whilst
producing a minimal impact to system performance. Similarly a user
running an arbritrarily large single application, such as say Lightwave,
will find that paging can become an excess when close to the physical
ram limits. This is no issue when handling that single application, but
the paging nature is not idealistic - even loading a "small" app such as
an explorer window can cause a massive re-page of the now unfocused app.
In this case, because the memory balence between apps is poor, and the
system takes no knowledge of each programs intentions - a bad decision
is made. In this case (one that I have spent a good deal of time on)
disabling the paging executive was the only way to get smooth non-paging
performance out of the system.
Finally, FYI - registry entries are rarely wasted by Micorosft - most
configuration options will change something when the switch is flicked
and they are put there for good reason! Why don't you try looking for
some information on those keys and see what other Micorosft articles you
find - if you read those the same way you read that last one, we'll have
you screaming that they are contradictory by the end of the week.
right.
On 8/14/05, James Tucker <[EMAIL PROTECTED]> wrote:
These rulings are intended for systems with dynamic environments and are
done for coninual performance puproses, and built for dynamic run-time
environments. This is not the scenario that a dedicated box will be
running, which much more resembles a static application set.
--
Clayton Macleod
get ye flask
You cannot get ye flask.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
