Subj : Re: Windows issues To : Finnigann From : Angus Mcleod Date : Fri Jun 10 2005 06:26 pm Re: Re: Windows issues By: Finnigann to Angus Mcleod on Fri Jun 10 2005 17:52:00 > > Interesting reading. However the problem remains, when an app says it > > cannot run for lack of resources... what do you do? > > AM> Make more RAM available by eliminating programs with large > AM> working-sets, or by buying more RAM. > > You don't seem to have read the link DM gave. Part of the rather long > web page explained why RAM defragers (or as I was hoping for; Ram > restorers) is a myth. I did read it. I knew much of it before. I did find the material on the specifics of how the OS moved pages from list to list to be interesting. And I like the way they search the freed-but-not-yet-cleared list of pages when a page-hit occurs -- clever optimization. Essentially, what I was telling you is run less programs (making more RAM available) or buy more RAM. What DM (and the article) was saying is that the OS is already doing a good job of freeing up unused memory blocks, so a utility to do that is probably only screwing with the METRIC so that it LOOKS like you have more memory, but don't really. Leaky programs are also being handled (by the OS) in the safest and most efficient way. The leaked pages (allocated, no longer needed so no longer accessed, but accidentally not freed) get removed from the leaky program's working set, so while they may be taking up space in the page file (or swap space or WTF you care to call it), they are not actually taking up any physical RAM. So no utility is going to do you much good here anyway. And by definition, in any system that uses paged memory, (demand paged, virtualized, or otherwise) de-fragmentation can not occur by definition and by design. Demand paging was invented to make RAM fragmentation a thing of the past. So any program that claims to de-fragment RAM is really doing little of value. Therefore, if your system tells you it needs more RAM, you have to reduce the size of the working sets of the tasks running -- not something you can actually achieve readily, nor would it necessarily be efficient to do so even if you could, because the OS spends it's time doing that anyway. So, you can only usefully reduce the size of the working set to zero by terminating the program. Or, go out and buy more physical RAM. :-) > And the rest of the article said that if you have xx% free ram, you are > wasting xx%. Well that sort of makes sense, but not logically. Of course > I tend to trail back on the understanding parts. Well, that is a matter for debate, but it is a fairly reasonable claim. If all of your programs, all together (OS too), including code, data, buffers, drivers and etc, come to (say) 200 meg of RAM and your system contains 256 meg of physical RAM, then we can debate the advisability of using larger buffers, etc, to utilize the extra RAM. But if the total memory requirements come to (say) 400 meg, and you only have 256 meg, you are going to have to page out 144 meg worth of pages. This will reduce the pages in the working set of your process(es) to less than 100%. Obviously, if you page out MORE than 144 meg, leaving free physical RAM in the system but burdening your processes with even smaller working sets, then you are wasting that free RAM. So yes, if you have 80% RAM in use, then you are probably "wasteing" the 20% of free physical RAM. You should page in some of the pages in the page file, in an attempt to make the processes run more efficiently (less page faults). Unless the page file is actually empty, in which case you should actually SELL a few of your RAM sticks... :-) > It has been my understanding that Windows apps fail to restore all of > the allocated resources upon exiting. They are thus lost to the system. > Eventually you must reboot your computer in order to recalim them. > > Every version of Windows claims to fix this problem. If this is actually happening (and I wouldn't be all that surprised) then essentially, the OS itself is leaking. Unless it is leaking system/ permanemt pages (what are they called in Mocrosoft-land?) then the OS should do the same as for userspace leaks. The page file will suffer, but leaked pages should wash out of physical RAM as a result of the normal OS operation. > If anyone has MORE insight on this, I would be fasinated to read about > it. If you are not already familiar with the concept of paged memory (and specifically demand-paged virtual memory) then that would be a good place to start. Does anyone have a reference to a basic explanation of paged memory systems? Possibly linked or leading to an introduction to demand-paged, virtual memory? I could probably do one, but I'm feeling lazy.... --- þ Synchronet þ Cry "Softly" then hit hard at The ANJO BBS .