uh, yeah. Like I said, you need a refresher. It's quite apparent from your "disabling the paging executive" statement. Clearly you think you are disabling something called the "paging executive" which you think means you're causing the OS to hit the pagefile less. Sorry to tell you, but the setting you're talking about doesn't disable something called the "paging executive." What that setting does is stop pages from the "executive" from ever going out of ram and into the pagefile. i.e. the kernel, drivers, etc. It doesn't affect any applications in any way, shape, or form. Any applications you have running will still get pages paged out just as much/little as before you disabled paging of the executive.
side note: it's really not necessary to respond inline like that for something so short as this. It does nothing but make replying to such a short conversation take a lot longer than it needs to, since it takes forever to trim out all the stuff you've quoted. On 8/15/05, James Tucker <[EMAIL PROTECTED]> wrote: > How many kernels have you built? > > > This statement bears no meaning on what I said. This rule is still for a > dynamic environment. > > > 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). > > 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. -- 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
