Jump to content

Registry Myths #1 - IoPageLockLimit


dirtyepic

Recommended Posts

Hello.

Does seeing "EnablePrefetcher"=dword:5 make you go like this -> :angry: ?

When someone happens to mention setting AdditionalCriticalWorkerThreads to 100, do you have an urge to beat that person about the head yelling "THE MAXIMUM IS SIXTEEN YOU $@%#& MORON!"? :realmad:

If this describes you, then you should really seek the attention of a certified psychologist. :no:

But for anyone who hates registry myths, regardless of sanity, this thread is for you. :yes:

Registry Myths #1: IoPageLockLimit

sample misinformation:

This tweak boosts the Input/Output performance of your computer when it is doing a large amount of file transfers and other similar operations. This tweak won't do much of anything for a system without a significant amount of RAM (if you don't have more than 128 MB, don't even bother), but systems with more than 128 MB of RAM will generally find a performance boost by setting this to between 8 and 16 MB. The default is 0.5 MB, or 512 KB. This setting requires a value in bytes, so multiply the desired number of megabytes * 1024 * 1024. That's X * 1048576 (where X is the number, in megabytes). Test out several settings and keep the one which seems to work best for your system.

[source: http://www.subvers.com/technobabble/html/tweaking.htm]

Configure the amount of memory that can be locked for I/O Post Comment

There is a limit for how much memory the system can lock for I/O (Input/Output) operations. Increasing the limit might benefit applications or drivers, which are highly dependent on highspeed network or harddisk access, as it will allow a larger amount of outstanding I/O.

This DWORD value specifies how much memory (in bytes) that can be locked for I/O operations:

[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Session Manager \Memory Management]IoPageLockLimit=0 (0 = Calculated at boot, Default = 0)

One can use the following chart for finding a value, though the best value is found by testing:

Total RAM(MByte) IoPageLockLimit(Hex) Max Value

64 0 Total RAM minus 7 MByte

64-200 800000 Total RAM minus 16 MByte

256-500 1000000 Total RAM minus 16 MByte

512+ 2000000 Total RAM minus 64 MByte

[source: http://snakefoot.fateback.com/tweak/winnt/tweak.html#IOLOCK]

Anyone who has done any kind of registry tweaking has seen IoPageLockLimit. It's all over the net, from Winguides, to Pure Performance, to Kelly's Korner, to TechSpot, to even Ars Technica. It's in every tweaking program you've ever used and most you haven't. Even the hallowed Expert's Exchange endorses this registry entry, although no one seems to be able to agree on exactly what format the values are supposed to be in.

What if I told you that this registry entry does absolutely jack? In fact, it isn't even read by the OS, or any other function of the system.

Wait a minute, you say. If this registry entry is bunk, then explain this:

http://www.microsoft.com/windows2000/techi...entry/29932.asp

Big Daddy MS itself says this thing works. So what do you say to that, Mr. Fancypants?

I say yes, you're right, it's true. In Windows 2000 RTM it was a real and valid setting. However, starting with W2000 SP1 and continuing with every subsequent release from 2K to XP to Server 2003 and everything in between, there is no reference to this registry value. In fact, in Windows XP and Windows Server 2003, the I/O Page Lock Limit is locked to 64mb.

Windows 2000 Power Users

Volume 3, Number 16

December 5, 2003

Killing a Myth or Three (or, Getting My Foot Out of My Mouth)

I was going to start talking about Longhorn this issue, but something more important (to me) has come up. Every now and then I realize that I have been inadvertently responsible for spreading a piece of information that turns out to be simply not true. When that happens, the only thing to do is sit down and make a meal out of my own words, sometimes salted liberally with crow.

Take, for instance, a certain Registry hack that is bandied around as being a performance-enhancer in both Windows 2000 and XP. This is the IoPageLockLimit hack, which (according to its proponents) allows you to change the amount of memory locked for exclusive access by the kernel. Setting this to a bigger value should lock more memory at once and in theory enhance performance. And indeed, it does do this -- but only in an RTM Windows 2000 machine. It does absolutely nothing in Windows 2000 Service Pack 1 and up, and absolutely nothing in Windows XP. This makes it effectively useless, since I know of no one in their right minds who runs Windows 2000 RTM on a production machine at this point in time.

How did I fall into this trap? Easy -- I tested it on a machine with Win2K RTM installed! It sure seemed to have an effect there, although not always a healthy one, and when I wrote about it I noted that this was a your-mileage-may-vary situation, and that seemed to be the end of it. The sheer amount of stuff out there to write about is intimidating, and I didn't want to spend weeks and weeks beating on the same issues until all but the most stalwart had fled or given up in boredom. I was applying a fair level of skepticism to the subject, but evidently it wasn't enough. (You can read what I wrote here: http://www.thegline.com/win2k/issues/2002/22.html)

One of the people who woke me up to how this whole IoPageLockLimit thing was a giant shill was Jamie Hanrahan of Kernel Mode Systems (http://www.cmkrnl.com). He had proof, he claimed, that the setting was absolutely worthless as of Win2K SP1 and up. He had run a string analysis on NTOSKRNL.EXE, looking for the actual Registry entry itself to see if it was being referenced by the kernel, and what he found was eye-opening. The RTM kernel references IoPageLockLimit. The SP1 kernel does not. Neither do any subsequent editions of the kernel; neither does the XP kernel in any of its incarnations. To double-check, he ran SysInternals' RegMon utility to determine if anything was, in fact, accessing that Registry entry at all, and the answer seemed to be a resounding no. There seem to be no references to the entry in any other system components, either. (I ran GREP on pretty much the whole Windows directory and came up empty.)

So why did some people report performance gains when they did this? There are plenty of explanations that have more to do with psychology and behavior than anything else. One of them is simple enough: that while making this tweak they did other things that may have legitimately affected their system performance (like do a defrag or clean up their boot acceleration cache, if they used XP). The other is nothing more than the placebo effect, where people perceive changes that simply aren't there, without having hard numbers to back it up. (Guilty!)

Now, the Ars Technica site, themselves no slouches, have reprinted the trick (at http://www.arstechnica.com/tweak/nt/IO-1.html), along with hard numbers to back it up -- but only under NT 4.0, not Windows 2000! Evidently a lot of people (myself included) have been mindlessly following the bandwagon that NT 4.0 = 2000 when it serves them and NT 4.0 <> 2000 when it does not.

On the one hand, this is bad news, because it means I've been inadvertently been spreading things which seemed to be facts, but which simply no longer have any truth to them, and haven't for some time. On the other hand, there is some good news here -- it means that the amount of stuff that needs to be tweaked in a Win2K or WinXP system is that much smaller, and that the system has apparently been made that much more self-regulating lately. I don't know about you, but I didn't particularly relish the thought of taking days to try and tweak my cache settings. (How does that song go? "Always ... look on ... the bri-ight side of life...") If it means I have to go and make a mess of retractions, then so be it. I'd rather do that than continue to knowingly be wrong.

I think an old adage is worth trotting out: Believe half of what you see and none of what you hear.

[source: http://www.thegline.com/win2k/issues/2003/16.html#1]

Full credit for discovering this registry myth goes to Windows 2000 Power Users (www.Win2KPowerUsers.com).

Link to comment
Share on other sites

  • 2 years later...

  • 1 year later...
I even took time to register on this forum - I had to reply in this thread. Its so wrong.


It's always funny for me to see how loads philosophers take tweaks, analyse them with their philosophical methods, find a problem, then proove this problem and finally - shout out loud that a tweak is a fake. Without giving it a good try.

In fact, I have a completely different view on IoPageLockLimit. After using and trying many others also, I can even say that its probably the best Windows XP tweak out there.



If you think Im overconfident, then think twice, because im not only confident, but betting my hand on this tweak. I used it on various PC's for last 4 years. Starting with a PII 350 / 512 RAM, thru PIII 1000 with 384, then Athlon 3200+ with 1GB, Athlon 2000+ and 512, and a couple others. It always works. It makes an instant feeling that system is managing the memory in better way. Applications load faster, HDD browsing is quicker and RAM is never getting stuck, always perfectly unloaded when applications are stopped. Without any doubts, I can say that this tweak made that PII 350 able to be a workstation. Slow, but it was really fine for basic work.


I recommend this tweak to every XP user on any machine, but make sure to pick the right value for it. I dont recommend using the values from applications like TuneXP or whatever. They are too high and will make your system work even worse. Good value in this tweak is the key to its own value...
Link to comment
Share on other sites

I don't know how I missed this back in the day. This exists, even on Vista and 2008, and if you physically set it you are causing the memory manager to call MmProbeAndLockPages to lock physical memory for stricly I/O operations (note that unlike drivers that call VirtualLock, these pages cannot be released back to the system if load requires).

It's determined on boot based on the amount of RAM in the system how much is locked. It used to be 512K in NT3.x and 4.x, with newer OSes this may have been reduced further. Note that setting a high value might increase performance, but especially on lower-memory systems this can cause resource exhaustion (no one but the I/O manager can use these locked pages, so you increase the risk that you could cause the system to be starved for resources if it gets too busy for the memory at hand, and you'll either start paging frequently or potentially bugcheck.
Link to comment
Share on other sites

  • 3 weeks later...
So I'm a bit confused now. Does this tweak work? I'm currently researching loads of tweaks in order to find ones I can apply for most configurations and I thought this one was a gem but no I don't know if it does as advertised and what is a good value to use.

I would try some benchmarking and testing except I'm already snowed under just trying to verify what tweaks do and what values are best since it would be impossible for me to test each one for a range of values and verify that a given value will not have a negative impact under a likely circumstance.
Link to comment
Share on other sites

[quote name='Rhuaidhri' post='798569' date='Sep 23 2008, 12:52 AM']So I'm a bit confused now. Does this tweak work?[/quote]Define "work" ;). If you mean does it physically lock pages in RAM for only the I/O subsystem to use, yes. If it provides marked improvement over the defaults the box uses otherwise, probably not in most cases.

Link to comment
Share on other sites

Well that answers that. The setting is still read and applied by XP but as to if it will impact performance, probably not.

I'll add it to my list of stuff to test and benchmark and some stage in the distant future but ignore it for now. Thanks.
Link to comment
Share on other sites

According to Microsoft, the OP is right:

[quote]IoPageLockLimit

This registry key isn't used in Windows 2000 Datacenter Server and is no longer used in Windows 2000 starting with Windows 2000 Service Pack 1[/quote][i]Source: Inside Windows, Third Edition, chapter 7: Memory Management[/i]

The authors of that book are David A Solomon and Mark E Russinovich. David Solomon was given access to the source code of Windows by Dave Cutler at Microsoft and Mark Russinovich needs no introduction.

If anyone is going to contradict these two guys you need a lot more evidence than personal opinions!

One tiny piece of that evidence might be that the Microsoft link in the OP (contradicting him) has been pulled.

There's also a Microsoft written PowerShell script that references IoPageLockLimit, but when you trace the reference link back, it goes nowhere too, because the one thing Microsoft then [i]don't[/i] do is mention IoPageLockLimit.
Link to comment
Share on other sites

[quote name='schloss' post='798918' date='Sep 24 2008, 10:40 AM'][i]Source: Inside Windows, Third Edition, chapter 7: Memory Management[/i]

The authors of that book are David A Solomon and Mark E Russinovich. David Solomon was given access to the source code of Windows by Dave Cutler at Microsoft and Mark Russinovich needs no introduction.

If anyone is going to contradict these two guys you need a lot more evidence than personal opinions!

One tiny piece of that evidence might be that the Microsoft link in the OP (contradicting him) has been pulled.

There's also a Microsoft written PowerShell script that references IoPageLockLimit, but when you trace the reference link back, it goes nowhere too, because the one thing Microsoft then [i]don't[/i] do is mention IoPageLockLimit.[/quote]
[url="http://www.msfn.org/board/index.php?showuser=202233"]@schloss[/url], Please check your PM.
Link to comment
Share on other sites

@jcarle
Yes, I am aware of that. I agree! The vast majority of the OP is also about Windows 2000. However, I am also aware that this topic has since branched to other OS as well. That's why I was careful in choosing my quote.

@cluberti
Noted -- thanks.
Link to comment
Share on other sites

[quote name='jcarle' post='799075' date='Sep 25 2008, 06:34 AM']If you read your quote very carefully, it says that it's no longer used in Windows 2000... it does not make any mention of any other operating systems, past, present or future.[/quote]

The page I had bookmarked unfortunally doesn't work anymore, but Russinovich also stated somewhere in 2003 that Windows XP and Windows 2003 do not use this registry entry. It's a myth.

Edit: [url="http://home.comcast.net/~SupportCD/XPMyths.html"]More XP Myths[/url] ;)

Edited by beats
Link to comment
Share on other sites

  • 2 months later...

I didn't used the original link but was it about [url="http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/29932.mspx"]this[/url]?

btw. the link goes to the windows 2000 server registry resource. read the entry carefully - i didn't found any information that this is not working in windows 2000 server, did you? :) hell, wo wrote that piece of software? can we give him a call? :P

Edited by an3k
Link to comment
Share on other sites

  • 4 months later...
  • 2 months later...
[quote name='Rhuaidhri' post='798754' date='Sep 23 2008, 05:37 PM']Well that answers that. The setting is still read and applied by XP but as to if it will impact performance, probably not.

I'll add it to my list of stuff to test and benchmark and some stage in the distant future but ignore it for now. Thanks.[/quote]

Sorry for the dead thread resurrection, but someone recently pointed me here...

IoPageLockLimit is not read by XP, nor Server 2003, nor Vista, nor Server 2008, nor Win7. It has not been read by any version of Windows since Windows 2000 RTM.

Windows 2000 SP1 replaced it with IoPageLockPercentage... but that too was gone as of Windows 2000 SP2. Neither has returned.

The [i]mechanism[/i] of locking (sometimes called pinning) pages for I/O (usually, though not always, for DMA) of course still exists: all DMA has to be to locked pages. But there is no longer a registry value to specify a system-wide limit of how many pages can be locked at one time for this purpose.

(Well, of course you can create the registry value. But as a few minutes with strings.exe and ntoskrnl.exe should convince you, there's nothing in the OS that reads it.)

This is not something that gets chosen at I/O time based on available resources. If a driver specifies that it's doing "direct I/O", then the I/O manager locks the buffer (yes, with MmProbeAndLockPages) and builds a structure called an MDL to describe it before the driver ever gets called.

The implementation of the "limit" was this: If there are already so many pages locked for I/O that the new request's buffer would cause the current total number of locked pages for all outstanding requsts to go over the limit, then the new I/O request would be failed with STATUS_WORKING_SET_QUOTA. Note: "Failed", not "stalled".

I use the past tense because the entire mechanism seems to be gone completely. In particular, the global where the registry value was stored, MmLockLimitInBytes , is gone.

As is the string IoPageLockLimit from ntoskrnl.exe (or any of its variants). Again, this is for ALL versions of Windows since Windows 2000 RTM, or SP1 if you want to include IoPageLockPercentage.... not just Windows 2000 versions.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...