Slashdot Mirror
Ars Analysis Calls Windows 7 Memory Usage Claims "Scaremongering"
Via newsycombinator comes a reaction at Ars Technica to the recently reported claims of excessive memory use on machines running Windows 7. From the article: "I installed the XPnet performance monitoring tool and waited for it to upload my data to see what it might be complaining about. The cause of the problem was immediately apparent. It's no secret that Windows 7, just like Windows Vista before it, includes aggressive disk caching. The SuperFetch technology causes Windows to preload certain data if the OS detects that it is used regularly, even if there is no specific need for it at any given moment. Though SuperFetch is a little less aggressive in Windows 7, it will still use a substantial amount of memory—but with an important proviso. The OS will only use memory for cache when there is no other demand for that memory."
Though SuperFetch is a little less aggressive in Windows 7, it will still use a substantial amount of memory—but with an important proviso. The OS will only use memory for cache when there is no other demand for that memory.
I really wonder when people will get this. In the earlier thread I saw people commenting that Windows 95 didn't need so much memory and so on..
To state it again. This is not RAM memory you need, use or have purpose for. IF you do need it, it is zeroed-out and free'd to application in like 30ms (one frame in usual FPS games).
If you have fast memory, do use it to it's full extend.
Really? 30ms. Shit that's slow.
This IS RAM we're talking about here, right? y'know nanosecond stuff, 10^-9 not 10^-3 seconds.
Deleted
As I understand it, it doesn't cache data, it caches applications (and I think also fonts and other often-used things). So startup time for your web browser, e-mail client, IM client, and any other applications you use often will be much faster. For example, Google Chrome loads almost instantaneously on my system, from a cold start. It won't keep a memory cache of things that applications do, and hence it won't speed up compilation, rendering, etc.
For that matter, 2GB of RAM isn't a whole lot to cache with when you think about it. The sweet spot for Vista/Win7 is really around 4GB or higher for SuperFetch to really shine.
Screw the rules, I have green hair!
This is completely offtopic, but you seem to come with this message in every thread so I answer you one time here - I am from sweden, not uk.
Seems to use 1.3 gig no matter what I do. It's got 4 gig total. Boots in less than 2 minutes. It makes mistakes a lot faster than the old machine, which was just shy of a brick when I switched.
How about a moderation of -1 pedantic.
And though your English has some minor mistakes every now and then, it's not like you are writing in such a way that we cannot understand you. Your English is better than my grasp of Spanish by many miles. Congrats.
SSC
Linux uses available memory for cache, and rather aggressively. All available memory can be filled with cached file blocks. This happens routinely on systems which have big randomly-accessed files open, like databases.
There's nothing wrong with this, except that, once in a while, Linux hits a race condition in prune_one_dentry, causing an "oops" crash, when there's an unblockable need for a memory page and something is locking the file block cache.
This is one of the Great Unsolved Mysteries of Linux. Linus wrote about it in 2001 ("I'll try to think about it some more, but I'd love to have more reports to go on to try to find a pattern.. "). As of 2009, this area is still giving trouble. The locking in this area is very complex.
Programs and compilers have nothing to do with disk read/write caches, this is handled at the OS level.
Programs ask to read/write from/to disk and they have no idea where the OS get the data from.
You and the GP might be confusing CPU cache that has its own dedicated memory and disk cache that uses the OS RAM.
Everything I write is lies, read between the lines.
At boot, Windows is doing other things not prefetching. Turn superfetch on and monitor your active processes at boot, you'll see that the superfetch PID is sittng all the way at the bottom of everything. Its IO is negligible as is its CPU usage until AFTER everything else has loaded and your system has gone back to twiddling its bits for a few hundred thousand processor cycles.
Keep on knockin'
https://robbiecrash.me
The only data in the article you refer to was captured data from XPnet that said that >90% of RAM was in use in Windows 7 machines. There was no data saying it led to swapping, that was supposition.
http://www.computerworld.com/s/article/9158258/Most_Windows_7_PCs_max_out_memory
http://lkml.org/lkml/2005/8/20/95
if everyone is so afraid of their computer memory being used to the fullest, why do these people install so much of it?
Most users remember back to at least the 90s. You had to install enough ram to do what you needed (load the OS and program(s) - WinNT had the audacity to require 8MB to run well). There was no caching of any useful sort, so your free memory was really a measure of how many programs you could load. Programs, like Photoshop, added scratch files to overcome the physical RAM limits, but at a horrible performance penalty should have to actually use it. "Free RAM" became synonymous with "how many things you could do or open simultaneously."
All modern operating systems have moved on, but people haven't been educated about this. They remember how bad it was when they ran out of memory, and panic when the OS reports it's almost full. Honestly, it would be far better if MS would have reported the cached memory differently. I don't really care how much memory is used as superfetch cache most of the time - I'm more concerned with the total active usage. My netbook "only" has 2GB, but I do some 24/96 audio recording with it, and will occasionally work with photoshop images, so I am concerned if I have less than 500-600MB free when I open a session as I'm likely to exceed the physical RAM. I can read the data, so it's not a big deal, but others freak out about it.
Is it just my observation, or are there way too many stupid people in the world?
Not necessarily. Many programs commit large chunks of memory in case they need it later but only use a small portion initially. This simplifies program logic because you don't have to free and reallocate the buffer when you need more space, deal with potential reallocation failures etc. Or a program might want to specify a larger-than-default stack commit size to make sure it doesn't hit a stack overflow if it tries to extend the stack while the system is temporarily out of commit (most services and other system critical processes do that). Or it might map a copy-on-write view of a file, in which case commit is charged for the entire view but no extra physical memory is used until the program actually writes to the pages. Etc etc... The end result of this is that you can't really say anything conclusive about physical memory usage by looking at commit charge
Commit charge is a virtual memory metric. It's great for detecting memory leaks and deciding how big your pagefile needs to be, but not so great for understanding physical memory usage. Often it might seem like there is a correlation between commit charge and physical memory, but you can also find systems that are very low on available RAM yet have plenty of available commit, and vice versa.
Task manager now shows used physical memory (defined as Total - Available). Available memory is the most straightforward way to understand whether your system needs more memory or not, and this is why in Vista/Win7 it was chosen as the main indicator of "memory usage".
All good operating systems do this. My Mac, for instance has "inactive memory", which is not exactly the same as Windows, but close enough. If your memory is free, it's not doing anything for you. End of story.
I still cannot find the droids I am looking for...
While catering to the Apple fan-base a little too much for my tastes -- hits it right on.
It is scaremongering.
.
Cache is there for a reason -- idle RAM is useless RAM. Now, do I think that Windows allocation mechanism for idle RAM is right on? Of course not. It could use some tuning. It could have used some tuning since XP -- but is idle RAM stupid? Yes.
Anything that can update the pipeline between process/thread interaction with data before it has to go to disk -- is preferred.
However, Windows needs to be smart about what it caches and keeps in the pre-fetch. Frequently used and accessed rather than conditional stale.
That's the point.
Sort of.
The issue with ext4 had to do with dirty cache not being written to disk in a timely manner. This meant that you could have disk writes you thought had already happened and certain actions could get out of sync because of they way they'd been written.
The cache in this case is not dirty(in fact it's read only) so there's no risk of losing data (since most of the time the data on the disk and the data in memory are identical and when they're not the disk is right).
Except PAE is supported on all Pentium Pro and later Intel CPUs.
I don't know where you get the idiotic idea that it only works on 64-bit hardware.
Except it simply doesn't do that as you can easily demonstrate with test case programs. Memory used for cache is used but not reserved, so if a program needs it, it will simply free some of the cache and give it to the program. No swapping required. Swapping programs in order to maintain the cache would be idiotic, but Windows doesn't do this.
If you don't know where you are going, you will wind up somewhere else.