No announcement yet.

IoPageLockLimit really IS gone in XP. And a few other corre

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • IoPageLockLimit really IS gone in XP. And a few other corre

    I am the author of the text quoted from tweakxp.com , in the thread "Errors in "Tweaking Windows XP" guides", that ends with:

    "If you still don't believe it, try running MarkR's "regmon" tool, starting at boot time, logging all registry accesses to a file. Search the resulting log for references to DisablePagingExecutive and LargeSystemCache, which you will find, and for IoPageLockLimit, which you won't as of win2k sp1."

    I would have replied in that thread, but the moderator locked it. It is arguable whether the tone of the discussion in that thread merited locking, but there is just no ambiguity about the facts here: The IoPageLockLimit value is ignored as of Win2K SP1. Nothing and nobody reads it in Win2K SP1, Win2K SP2, or WinXP. Ever. The system doesn't even know that name any more. Something you can prove for yourself with the methods I described.

    The fact that heinz57 says "I use [it] set to 32 works great" means nothing. (If actually interpreted that way that would mean 32 BYTES, a ridiculously small number.) You could create a registry value called "MaryHadALittleLamb" and stuff it into this key and your system would "work great". Does that mean the system is using your new registry value? No.

    By the way, default and minimum values for IoPageLockLimit were always 512Kbytes. (K=1024 here.) So even under Win2K RTM, where the value actually is read, if you put a value smaller than 524288 in there, the system would just say "whups, too small" and set the value used internally to 524288. About half of the tweak sites I've seen recommend values smaller than this (sometimes further misstating that the value should be spec'd in KB, resulting in an even smaller number in the registry). Result, the system would just use its minimum of 512KB, so all those tweaks did essentially nothing even though the system WAS reading the value.

    Also, on those versions where it does work, it's important to understand that IoPageLockLimit does not reserve any memory. It's a system-wide quota, allowing the indicated amount of RAM to be "locked" against paging ("pinned" is the term used in some contexts) for the support of, and only for the duration of, currently-pending direct IO operations. "Direct IO" is a system mechanism most commonly used when the hardware is doing DMA. The purpose of "pinning" a buffer is to make sure it doesn't get paged out, and hence moved, in physical memory once a DMA controller has been given its physical address. But once the DMA operation is done, the buffer is unlocked (unpinned).

    So, the default value of 512Kbytes essentially says that you can have 512Kbytes worth of buffers for DMA transfers pinned into RAM at one time. Given that the typical disk IO transfer size is 64 Kbytes, this allows eight such transfers at a time. Now most systems only have one IDE hard drive, and perhaps a CD-ROM, and an IDE controller can only be performing one transfer at a time... so the most you'd ever likely use of this quota is 128 Kbytes. However, since this value does not represent a permanent reservation of RAM -- it simply allows the system to temporarily lock up to the indicated amount of RAM -- setting it to larger than will be used won't hurt.

    While I'm here:

    Setting "DisablePagingExecutive" to 1 does not "deactivate memory paging", and it does not disable the "paging executive". (There is nothing in the system that is called the "paging executive.") It disables the paging OF the executive, which is to say most of ntoskrnl.exe, and some (not all) of the other pageable stuff in system address space. (A notable exception is the file system cache, i.e. paging of the file cache is NOT disabled by this value.)

    If you have more than enough RAM for your workload, yes, this won't hurt, but then again, if you have more than enough RAM for your workload, the system isn't paging very much of that stuff anyway.

    Think of it this way: For a given amount of demand for RAM + a given amount of RAM, there will be a certain amount of paging. DisablePagingExecutive says "don't page the OS code or some of its data". But for given demand + amount of RAM, there has to be a certain amount of paging, so the result is that app code and data will be paged MORE. It's a tradeoff. The usual rationale for this tradeoff is that the system's code is used by all the apps, so it's better to keep the system's code in memory and let the apps page. Sometimes it is.

    By the way, you can never disable paging completely in this OS family. This is a virtual memory OS. Even removing the paging file won't disable paging -- the paging file is by far not the only file involved in paging. You'll just make it page to other files more.

    LargeSystemCache: The explanation for this one in the tweak guide is off the wall in more than a few ways. Briefly, this setting simply allows the system's working set (which includes the file system cache) to use proportionally more of physical memory, in relation to process working sets, than it otherwise would.

    It does not allow the file cache to use all but 4MB (4MB wouldn't be nearly enough for everything else that needs to be in RAM), and there is no "disk cacheing" that is used by the "4MB of memory left" (there is no "disk cache" in the NT family at all, only a file cache, and there isn't just 4MB of memory "left" in this case anyway).

    Where the "4MB" figure does come in is that LargeSystemCache also allows the "available" physical memory to drop well below 4 MB before the system begins aggressive memory reclamation; normally it does this at the 4 MB threshold. The result here is that if you have a stable applications mix (like on a server) that is mostly doing the same thing over and over, setting LargeSystemCache to 1 allows a bit more stuff to be kept in RAM. The tradeoff is that there will be very little free RAM available to support the paging in of new code or data.. so when that happens, some other stuff will have to be paged out. In other words, if you are short on RAM and you are doing a lot of startups of new apps, setting LargeSystemCache to 1 will probably not be a good idea. On the other hand, if you have plenty of RAM, it probably won't matter either way.

  • #2
    Hmm.. also...

    Part 1, tweak 11, prioritizing processes: The advice given there is misleading at best, dangerous at worst:
    While I’m checking my email, I might want a Normal priority for Max, but if I leave my Computer, I can increass it to ’RealTime’ to get the most rendering done. Easy!
    Easy perhaps, but not a good idea. Whoever wrote this does not understand how priorities work. When you leave your computer the CPU is 100% available for whatever lengthy jobs you've left running! If there is nothing else competing for the CPU, 3dmax (or whatever) will get ALL the CPU time, even if you set it to 'low' priority! It is not like the system constantly reserves some part of the CPU time for higher-priority threads even if there aren't any that want to run... The highest priority runnable thread gets ALL the CPU time. Even if that thread is of very low priority.

    (There will always be a few %, or less, used by some OS "housekeeping" functions. You don't want to interfere with these.)

    As for 'realtime', setting ANY app to the realtime priority class is very risky. Reason: there are several threads in the OS that run at lower priorities than that, and which perform functions vital to many applications and services. Running an app that depends on those functions (basically any interactive app) in the realtime class can get you into a deadlock situation, usually requiring a reboot, particularly if it's heavily compute-bound... as 3d rendering programs tend to be.

    Leave the priorities alone.

    Tweak 12 - The "IRQ8Priority" (Or IRQ(anything)Priority) value is ignored in this OS. Unlike IoPageLockLimit this one has NEVER been looked at by ANYTHING in the NT family (NT, 2K, XP). I don't know where this idea got started -- maybe it's valid in the 9x family, but that does not carry over to the NT family.

    Part two, Tweak 8: This is completely unnecessary and furthermore detrimental to performance in most situations -- those DLLs will get "unloaded" (actually simply replaced in memory) with new stuff on demand, as needed. In the meantime, keeping them in memory vastly improves app startup time.

    Finally -- Part two, Tweak 11, L2 Cache Tweakage: Another harmless but unnecessary tweak. This has been debunked thoroughly, and I'm frankly surprised it's still being passed around; see, for example, Detailed Explanation of SecondLevelDataCache .

    Briefly, unless you are running a very old processor, this will have no effect. Even on those processors, it does not control how much of the cache gets used (there is no way to control that in the x86 architecture); it only affects the sizing of certain OS data structures so as to take the most advantage of the L2 cache for those structures. As they mention, the measurable performance difference is tiny even on old CPUs where this setting matters.

    Briefly, someone needs to do some better homework on some of these "operating system internals" things.

    On the other hand, some of the "appearance and usability" stuff is very useful. While I'm thinking of that, does anyone know how to get XP to stop showing remote computers' descriptions in BOTH the "name" and "comments" columns in Details view?

    Comment


    • #3
      Thanks for the information. We will look at adding this in new and or updated guides in the future!
      Cameron "Mr.Tweak" Wilmot
      Managing Director
      Tweak Town Pty Ltd

      Comment


      • #4
        thank you...this is the kind of proof i was asking for in the other thread
        At the request of wiggo ;)

        Comment


        • #5
          Re: IoPageLockLimit really IS gone in XP. And a few other corre

          Thank you jeh. You're informations are very important to me and to others ones. You are the best.
          Last edited by partystar; 04-20-2007, 11:45 AM.

          Comment


          • #6
            Re: IoPageLockLimit really IS gone in XP. And a few other corre

            Now I am new around here… Can anyone explain me what is MarkR, please? It seems to be something important, but I do not know the meaning of it. <o:p></o:p>

            Comment


            • #7
              Re: IoPageLockLimit really IS gone in XP. And a few other corre

              Welcome. You have just re-resurrected a thread from 2002. From 2 minutes of research MarkR appears to be the author of the original RegMon program.
              Antec 900 case (4 120mm and 1 200mm lighted fans + UFO flashing light set + 2 12" and 1 6" Mutant Mods meteor lights) - Aerogate ll thermal controller - Asus M2N-e SLI - AMD 64 X2 AM2 6400+ - Corsair TX650 PSU - MSI 450GTS Cyclone OC - 2 X 2GB Patriot Extreme Performance PC2 6400 RAM - SATA 320 GB Seagate HD, SATA 300GB Maxtor HD and IDE 80 GB Samsung HD - Floppy Drive/Card Reader Combo - LG SuperMulti Lightscribe 18x DVD RW - Plextor PX-716A DVD r/rw - Windows 7 Home Premium 64

              Crude but Effective ... it is a way of life.

              Comment


              • #8
                Re: IoPageLockLimit really IS gone in XP. And a few other corre

                Thanks PrairieDawg, sorry for the dumb question, I just discovered the search function :D

                Comment

                Working...
                X