Mark Russinovich: Inside Windows 7 | Going Deep

Mike Diack

Following up Dimebags comments, although as we all can see, Windows I/O handling is problematic, moving onto the more specific issue of the OS hanging while dealing with CDs / DVDs etc (especially those that have physical damage), I'm not convinced that the problem is Windows specific - I'm rather more convinced that most/all drive firmware doesn't handle such media well.

I've seen similar lockups while trying to read damaged media in OS/2 and Linux. I wonder whether it's not due to the DMA access to the damaged disc "locking the bus" and preventing other activity. I have a strong suspicision that this is the case, since when I've turned DMA off and used the same disc, the lockup doesn't occur (although obviously without DMA, for normal discs, you get very suboptimal performance).

Mike

FireRx1

[img]http://img.photobucket.com/albums/v209/firerx/whatswronghere-1.jpg [/img]

I hope they fix this! Todays Core i7 965/975's don't use just the FSB/QPI to identify the BCLk of a processor. It also uses the mutli settings. It appears a kernel issue , and I've sent this to the team.

FireRx1

Perhaps this should be addressed to the team, but as Computing is pushing forward to the x64 bit realm, there are issues that needs to be addressed before launch, or Windows 7 will be behind the curve. One issue I've noted is Windows still refers to the FSB to determine the BCLK speeds on most processors. This was fine, a year ago when processors speed calculations were dependant on the FSB. However, with the advent of the new Intel Core i7 processors, especailly the Extreme additions, the BCLK is determined by the Multi settings, rather than the the QPI/FSB setting alone. For example:

My BCLK on my Core i7 965 EE is 24x, with a QPI of 133mhz. That's is seen in bios , and windows at 3.2 ghz. However, Many users, including myself, overclock our processors. So when I set my multi to 34x with the same QPI I'm at 4.5ghz in bios. But in Windows it remains 3.184Ghz. This is because Windows is using the new processors QPI settings to determine the BCLK only, when in reality it should be using the multi's setting also to determine the clock speed of the processor. I bring this up because I sent feedback on this issue, and have yet to see an update to addrees it. As you know, most new computer will have the intel Core i7 processors in them. It would be nice to have windows read them correctly, versus having to use third party software to get correct processor speed ratings.
Thanks!

noisywan

Windows 7! Hurray!

Does that mean Windows Explorer will no more hang all tasks and go into 'not responding' state while trying to read a CD inserted in CD-ROM drive ?

There are rumors that it can also calculate the estimated time correctly while copying files and does not hang while browsing network... If it's true then Win7 is my dream OS!

Charles
Welcome Change

In reply to noisywan

#Jun 11th @ 5:32 AM

Ha ha.... Why don't you download and install the RC build. Then your need to troll will be greatly reduced and your appreciation for Windows greatly increased.

C

perris

I had a conversation with landy a while back talking about memory management in xp and we were discussing changing how windows pro-actively writes pages to the pagefile in vista

he said there was no cue for that function there might be a hardrive bottleneck between pagefile writes and user writes.

landy said they were thinking about giving this page write a cue policy but hadn't done it in vista, (it was still longhorn at the time of this conversation)

I'm wondering if it was ever done for vista and if not if they addressed that issue in seven

Charles
Welcome Change

In reply to perris

#Aug 6th @ 4:12 AM

Hi,

As of Vista and Win7, MM’s policies for determining when to write pages out to the paging file do not take into account other disk activity.

C

perris

In reply to Charles

#Aug 7th @ 11:18 AM

shame charles as this is a hit people do happen to notice when they have an abundance of memory

I understand when pages are being written for cause, however nt writes pages pro-actively, long before they're even considered a candidate for release

as I mentioned with landy, (who did say this was going to be considered), this pro-active writing to the pagefile when the system is not under pressure should enjoy a differant policy then when the pages are being written actively

I understand only unique images in ram and not represernted on disc or the network are written to the pagefile however if there is no memory pressure yet there is hardrive use I think it would smooth things out if there was a "no memory pressure policy" for pages that aren't even a candidate for release

no?

Charles
Welcome Change

In reply to perris

#Aug 7th @ 12:03 PM

"no?"

Consideration is not definitive.

C