Why doesn't Intel patch MS's OS schedulers?

[VirtualLarry]

What with the issue of "thread bouncing" (between cores) with the current XP scheduler (and I assume Vista too??), thrashing caches, and basically nullifying any advantage to Nehelems new "turbo mode" (where one core gets overclocked, while the other cores sit unused) - why doesn't Intel help out Microsoft, in order to get the biggest advantage out of Intel CPUs, by writing a patch for the OS scheduler?

 

[Idontcare]

I'm a "follow the money" kind of guy...so when something isn't happening I usually assume it means the smart folks (1) know well of the issue, and (2) have already done the feasibility study and came to the conclusion it would either (1) not make them enough money to remedy the situation, or (2) it would not cost them enough customers (lost sales) in not remedying the situation to make it worth pursuing closure.

Was it Ford and the Pinto where the accountants convinced executive management that not fixing the fuel-tank issue would cost them less money (from lawsuit payments) than the alternative option of fixing it?

So my basic assumption here would be that neither Intel (or AMD) nor Microsoft (or Apple) are convinced they are losing out on meaningful sales just because their product involves the thread migration phenomenon.

This is one of the many downsides to monopolies. They pretty much get to decide what features you are going to get to choose from (RDRAM anyone) as well as deciding whether they are going to invest their shareholder equity into resolving issues that the measly consumer might have with their product.

Little to no competition means no one is left to improve on features as a way to differentiate their product from the competition. Microsoft and Intel have no fear of thread migration, that's our problem not theirs.

 

[SunnyD]

I doubt Microsoft would give Intel "that much control" over their OSes let alone that piece of code. No matter how much they like each other. Besides, Intel can write nice compilers, but if they could write a decent OS scheduler why stop there?

 

[Flipped Gazelle]

Originally posted by: Idontcare
Was it Ford and the Pinto where the accountants convinced executive management that not fixing the fuel-tank issue would cost them less money (from lawsuit payments) than the alternative option of fixing it?

Yup. A design requirement was to keep the cost below a certain threshold, and a redesigned gas tank would have exceeded it.

 

[Phynaz]

If you are are looking in task manager, that's the problem. It basically lies about where the utilization is.

Run your favorite DC client on one core of dual core machine. Task manager will show two 50% utilized cores. Now fire up your temperature monitoring tool. See that one hot core and one cool core? That DC thread is staying pinned on one core, or else both cores would be the same temp.

 

[Fox5]

Originally posted by: SunnyD
I doubt Microsoft would give Intel "that much control" over their OSes let alone that piece of code. No matter how much they like each other. Besides, Intel can write nice compilers, but if they could write a decent OS scheduler why stop there?

AMD has some kind of scheduling patch you can download for their processors.

But I don't think Intel even has a custom scheduler for Linux, why would they write one for Windows?

 

[Idontcare]

Originally posted by: Phynaz
If you are are looking in task manager, that's the problem. It basically lies about where the utilization is.

Run your favorite DC client on one core of dual core machine. Task manager will show two 50% utilized cores. Now fire up your temperature monitoring tool. See that one hot core and one cool core? That DC thread is staying pinned on one core, or else both cores would be the same temp.

Out of curiosity I just ran this experiment.

In my case I am testing a quad and I am using a single-threaded program which fully loads a single-core. I disabled C1E and EIST in the BIOS so there is no funny business in the idle temps vs. load temps for unloaded idle cores while one core is fully loaded.

I had coretemp 0.99.3 log the temps in 1s intervals. I imported the temperature data into Excel and then created a delta temperature plot over time.

The baseline temp for each core was taken as the idle temperature as reported by Coretemp. The graph indicates the increase in core temperature over the idle temperature during the single-threaded application fully loading and eventually stopping.

Here's the results for no affinity set in task manager:
http://i272.photobucket.com/al..._bucket/NoAffinity.jpg

We see all cores rise in temperature during the run and the temperature per core actually spikes a lot (lots of jitter in the temperature data). I included a screen capture of task manager during the run as well, you can see it report all 4 cores are equally loaded at 25% utilization per core.

Here's the results when I set the affinity to Core#2 in task manager:
http://i272.photobucket.com/al...bucket/SetAffinity.jpg

We clearly see Core#2 rising in temperature markedly more so than the other three idle cores (confirmed idle by the included task manager screen capture). Core#2 is nearly 9°C warmer when fully loaded versus idle.

It is also interesting that the temperature data is now quite stable point-to-point, none of the jitter we saw in the first test where the thread was not locked. To me this is more evidence that the thread is bouncing core-to-core when affinity is not set versus when affinity is locked to a specific core.

In my opinion the data quite clearly prove that thread migration as reported by task manager is very real and is in fact occurring as confirmed by the temperature results for the given CPU cores.

 

[Phynaz]

Weird, just ran WCG with on thread on a mobile C2D, and one core is 47C, and the other is 69C.

Anybody else want to try?

 

[VirtualLarry]

I think most DC apps have code that explicitly pins threads to a core, it's more efficient that way. At least, the DC app that I run, SeventeenorBust does that when you install it as a service (which is required to take advantage of more than a single core).

 

[cmdrdredd]

Yes, DC apps can set affinity manually and force one core to run a thread. Your typical app can't do the same and windows ends up spreading it around between what's available. It's ineffecient, I wish it would work more like MacOS X which seems to handle it better. Course, it's built based around a very specific set of system requirements and options.