Vista and Win7 has I/O priorities, but it is done in the I/O stack above the hardware. Low priority IO that is not in flight on the hardware will be delayed. The longest a single low priority I/O operation can block access to the hardware is the length that it takes to complete, which is relative short, less than 10 ms typically. Once higher priority I/O requests are received, low priority I/O is delayed until all higher priority I/O is completed. After no higher priority I/O requests are received for a significant period, then low priority I/O resume.
SuperFetch has an extremely small interference with foreground application I/O in Win7 due to this mechanism.
In addition, if FF is a process you use frequently, SuperFetch will have the relevent code and data files in memory before you launch it.
The disk track buffer is used mostly for disk writes, since the I/O bandwith to the rotational media can't keep up with the bus transfer bandwidth.
Please show where I said the whole file was loaded. Oh, that's right you can't. Windows uses demand paging, and if you turn of the page file, it works like it should and not what you claim I said.
No that tells the OS to keep all of your process private pages in memory. Anything backed by a file will be purged from memory, like code and data files when other processes need memory.
Sequential reads from code files (.dll,.exe) and data files tend to be faster than random IO from the page file. How much forcing the OS down this path impacts performance is very dependant on the memory usage patterns of the system and all of the processes executed on it.
That is an example of demand paging. There are lots of different ways a modern memory manager pages, and what was described above is paging for those that understand how OS memory management really works.
If you disable the page file, you don't disable demand paging (guys, swaping went out of vogue eons ago). What you do is you chnage how the OS can respond to memory pressure by forcing it to write out or repurpose pages of files in memory. For example the code not currently being executed, or data files. Remember only process private pages are writen to the page file (think heap and virtual alloc).
It also forces the OS to use more physical memory for things like thread stacks, which grow dynamically, and change thier physical memory usage. If you disable the page file the entire commit size of the stack (typpically 1 MB for windows apps per thread) comes from physical memory. With the page file enabled, only a few stack pages will be in physical memory and the rest are accouted for by space reserved in the page file. Since a typical system with a few applications will have between 500 and 1,000 threads you could be blowing a 0.5 to 1 GB on stack pages the system will never use.
Disabling the page file is an extreemely bad idea if you really want your system to remain performant. There are cases where it can help, but most users don't know enough about how demand paging works to know when it is appropriate.
I couldn't more strongly disagree with your assessment of NH government after having lived there for 21 years. Perhaps you didn't want to participate in your local government, or maybe you had lived in the border area that has been heavily influenced by migrants from the Republic of Massachusetts.
Except the memory manager doesn't garbage collect files or executables. Nothing will be written to the page file for these items on the standby list. Also SuperFetch does cache private data that will need to be written to the page file.
What your post indicates is a misunderstanding of how OSes (and I mean all OSes) manage memory.
Yes I can, you are spreading FUD.
The two development teams are composed of different engineers, so simultaneous releases of SP's are common.
Win7 features are public, with lots of press. Leave your parents basement once in a while.
The most common Windows Release cycle is 3 years.
The blog also says 6.1 was chosen because:
There's been some fodder about whether using 6.1 in the code is an indicator of the relevance of Windows 7. It is not.
Windows 7 is a significant and evolutionary advancement of the client operating system. It is in every way a major effort in design, engineering and innovation. The only thing to read into the code versioning is that we are absolutely committed to making sure application compatibility is optimized for our customers.
DPC and ISR time is chnaged against the Idle Process for resource accounting. So CPU usage by this process means usage by deffered Procedure Calls or interrupt service routines (devices).
The Windows Performance Toolkit can be used to understand what is happening.
http://msdn.microsoft.com/en-us/library/cc305187.aspx
Re:Didn't measure memory correctly
on
Chrome Vs. IE 8
·
· Score: 1
Yes, the Devil Mountain "research staff" appear to be very naive when it comes to measuring memory usage for processes. As a result they are counting all of the shared code pages, open data files, and other shared memory pages for each process.
http://msdn.microsoft.com/en-us/library/ms684891(VS.85).aspx
Time to take off the tinfoil had sonny.
If IE7 still sent out URLs visited after you told it not to, the lawyers would have a field day, and MS would have a huge PR problem. I am sure this was checked and double checked numerous times to make sure that it didn't happen.
Except that isn't what SuperFetch does. SuperFetch is a policy extension to the memory manager. All the script is doing is adding files to the filesystem cache.
It is usally best to know something about which you speak. Go here and watch the video.
http://channel9.msdn.com/showpost.aspx?postid=2424 29
This isn't how SuperFetch works. What you are describing is prefetching, which has been is a number of OS platforms for a long long time.
If you want to know more about SuperFetch go here:
http://channel9.msdn.com/showpost.aspx?postid=2424 29
Slashdot Mirror
Vista and Win7 has I/O priorities, but it is done in the I/O stack above the hardware. Low priority IO that is not in flight on the hardware will be delayed. The longest a single low priority I/O operation can block access to the hardware is the length that it takes to complete, which is relative short, less than 10 ms typically. Once higher priority I/O requests are received, low priority I/O is delayed until all higher priority I/O is completed. After no higher priority I/O requests are received for a significant period, then low priority I/O resume. SuperFetch has an extremely small interference with foreground application I/O in Win7 due to this mechanism. In addition, if FF is a process you use frequently, SuperFetch will have the relevent code and data files in memory before you launch it. The disk track buffer is used mostly for disk writes, since the I/O bandwith to the rotational media can't keep up with the bus transfer bandwidth.
Please show where I said the whole file was loaded. Oh, that's right you can't. Windows uses demand paging, and if you turn of the page file, it works like it should and not what you claim I said.
No that tells the OS to keep all of your process private pages in memory. Anything backed by a file will be purged from memory, like code and data files when other processes need memory. Sequential reads from code files (.dll, .exe) and data files tend to be faster than random IO from the page file. How much forcing the OS down this path impacts performance is very dependant on the memory usage patterns of the system and all of the processes executed on it.
That is an example of demand paging. There are lots of different ways a modern memory manager pages, and what was described above is paging for those that understand how OS memory management really works.
If you disable the page file, you don't disable demand paging (guys, swaping went out of vogue eons ago). What you do is you chnage how the OS can respond to memory pressure by forcing it to write out or repurpose pages of files in memory. For example the code not currently being executed, or data files. Remember only process private pages are writen to the page file (think heap and virtual alloc). It also forces the OS to use more physical memory for things like thread stacks, which grow dynamically, and change thier physical memory usage. If you disable the page file the entire commit size of the stack (typpically 1 MB for windows apps per thread) comes from physical memory. With the page file enabled, only a few stack pages will be in physical memory and the rest are accouted for by space reserved in the page file. Since a typical system with a few applications will have between 500 and 1,000 threads you could be blowing a 0.5 to 1 GB on stack pages the system will never use. Disabling the page file is an extreemely bad idea if you really want your system to remain performant. There are cases where it can help, but most users don't know enough about how demand paging works to know when it is appropriate.
It may not be, and that is the whole point. Live free or die: Death is not the worst of evils. -- Gen John Stark http://en.wikipedia.org/wiki/Live_Free_or_Die
I couldn't more strongly disagree with your assessment of NH government after having lived there for 21 years. Perhaps you didn't want to participate in your local government, or maybe you had lived in the border area that has been heavily influenced by migrants from the Republic of Massachusetts.
Except the memory manager doesn't garbage collect files or executables. Nothing will be written to the page file for these items on the standby list. Also SuperFetch does cache private data that will need to be written to the page file. What your post indicates is a misunderstanding of how OSes (and I mean all OSes) manage memory.
Yes I can, you are spreading FUD. The two development teams are composed of different engineers, so simultaneous releases of SP's are common. Win7 features are public, with lots of press. Leave your parents basement once in a while. The most common Windows Release cycle is 3 years. The blog also says 6.1 was chosen because: There's been some fodder about whether using 6.1 in the code is an indicator of the relevance of Windows 7. It is not. Windows 7 is a significant and evolutionary advancement of the client operating system. It is in every way a major effort in design, engineering and innovation. The only thing to read into the code versioning is that we are absolutely committed to making sure application compatibility is optimized for our customers.
You have no clue at all about which you attempt to speak.
DPC and ISR time is chnaged against the Idle Process for resource accounting. So CPU usage by this process means usage by deffered Procedure Calls or interrupt service routines (devices). The Windows Performance Toolkit can be used to understand what is happening. http://msdn.microsoft.com/en-us/library/cc305187.aspx
Sysinteranls tools are good, but if you really want the nitty gritty details on what is happening use the Windows Performance Toolkit. http://msdn.microsoft.com/en-us/library/cc305187.aspx
Yes, the Devil Mountain "research staff" appear to be very naive when it comes to measuring memory usage for processes. As a result they are counting all of the shared code pages, open data files, and other shared memory pages for each process. http://msdn.microsoft.com/en-us/library/ms684891(VS.85).aspx
This is the correct answer. More details are available here; http://channel9.msdn.com/Showpost.aspx?postid=2314 38
Time to take off the tinfoil had sonny. If IE7 still sent out URLs visited after you told it not to, the lawyers would have a field day, and MS would have a huge PR problem. I am sure this was checked and double checked numerous times to make sure that it didn't happen.
Except that isn't what SuperFetch does. SuperFetch is a policy extension to the memory manager. All the script is doing is adding files to the filesystem cache. It is usally best to know something about which you speak. Go here and watch the video. http://channel9.msdn.com/showpost.aspx?postid=2424 29
This isn't how SuperFetch works. What you are describing is prefetching, which has been is a number of OS platforms for a long long time. If you want to know more about SuperFetch go here: http://channel9.msdn.com/showpost.aspx?postid=2424 29
Sony thought the same thing when he discovered the Rootkit. Russinovich is a tough and smart cookie.