Originally posted by: bsobel
Actually, W2K doesn't make the distinction between virtual and physical CPUs at all.
That was the point I was trying to make (apparently I didn't realize you were making it too). My further point was the fact that since it doesn't make a distinction it misschedules threads (specifically in a SMP/HT machine, but to a bad enough way to a single proc/HT machine).
Well, my contention is that if the MPS-spec tables are layed out correctly, then the first two active tasks should be spread out to the first two active (physical) CPUs, and only when there are three or more tasks should they be scheduled on the following two (virtual) CPUs. W2K can do this, because it relies on MPS. So your worst-case scenario, that of always scheduling tasks on a physical+virtual CPU, instead of physical+physical, should never happen in practice.
Originally posted by: bsobel
The OS has to participate in that scheduling. You can layout the physical procs first, but the OS is going to evenly distribute work load across the all procs, where what it should do is distribute the most work intensive items to the physical procs. Further, it needs to make affinity decisions if one of the physical cpu's becomes more available, a thread may need to take the hit to move to the other cpu.
I'll give you that, that in the scenario of three tasks running, two on physical CPUs, and one on a virtual CPU, if one of the tasks scheduled on the physical CPU completes, W2K is not likely to be HT-aware enough to re-schedule the task running on the virtual CPU to the one running on the other physical CPU. But there are performance costs with doing that too, in terms of non-shared L2 cache-thrashing. Regardless, that is a potential performance optimization, not a core feature of support.
(Not to mention, one aspect of HT, is to squeeze more efficiency out of the long-pipeline P4, and by scheduling two tasks across two physical CPUs, the potential performance efficiencies of HT are actually lost that way, although I'm pretty-sure overall system performance would still be slightly higher if running on indepedent physical CPUs because of the execution resources available, even if more of those resources "go to waste".)
To make my point quite simple, and not to drag this out any longer:
Intel specifically designed their implementation of SMT, "HT Technology", to be a backwards-compatible, drop-in replacement for existing SMP systems, in order to remain compatible with the existing base of SMP-capable OSes. (IMHO, in order to assure the acceptance of that technology, they really didn't have much of a choice other than to make it backwards-compatible that way. It was quite clever.)
My assertion is, therefore, that
any MPS-spec-compatible SMP x86 OS, should support HT fine, and guess what - they do.
I guess the point of contention is the term "fully".
In that respect, I do clearly admit, that it is possible to slightly optimize scheduling, based on the knowledge that one CPU is really only phantom, and doesn't have its own set of execution resources.
My contention, with the "MS FUD", is that MS has clearly prompted XP as being "optimized for HT Technology".. but that
does not mean that Win2K is somehow not compatible, or does not support HT. How optimization of one OS to support a feature, implies that older OSes don't support that feature, is beyond me, especially since Intel spent a lot of time and effort insuring that backwards-compatible support.
If the meaning of "fully" support HT, means that there is a requirement for greater performance overall with it enabled, vs. disabled, I totally
disagree with that, because that is entirely dependent on what kind of execution tasks there are to run. I'm sure that there are plenty of example cases that I could dig up, under XP, that enabling HT causes a performance hit (desktop loads), whereas, with a different set of test cases, it could show that enabling HT under W2K causes a performance advantage (server loads).
Originally posted by: bsobel
Your going to need to provide data to backup that assertion, as I assert that is NOT how home users are using (abusing hibernation), nor have I seen any evidence to the contrary.
Here's two that I've seen recently, only in the past week:
http://www.dslreports.com/foru...ark,11279052~mode=flat
http://forums.storagereview.ne...ex.php?showtopic=16817
If MS hands the users a gun, pointed right at their data, but totally neglects to teach the user how to hold it, aim it, clean it, and otherwise use it responsibly, then what is the responsible message to send to users in that case, generally? Mine is: "Don't ever pick up that gun." Quite simple, really.
And I
did say "mis-use" in my original statement about Hibernation in this thread. Sorry if that was overlooked, or if I had some extra commas in there that caused it to not parse out correctly.
Originally posted by: bsobel
If the enum is different hibernation will tell the user that the old hibernation data must be discarded. The file system is guarenteed to be intact, but any open unsaved data will (obviously) be lost.
Well, to me, that's still dataloss (unsaved docs), which goes against the concept of a workable hibernation scheme (reliable persistance). Therefore it is unsafe.
Again my question with regards to XP's ansync boot-up loading process - wouldn't that tend to, due to various hardware-initialization race-conditions, necessarily make hibernation under XP totally unsafe? Because there would be no guarantee of deterministic initialization, even when the hardware wasn't changed? I guess the question is, how much does the hardware enum data have to be different, in order for XP to "punt" and dump the user's data? Would PnP resource-allocation changes, that cause enumeration-order differences between multiple instances of hardware with the same PnP ID, cause that to happen? (Eg. "Clear CMOS", "Clear NVRAM", "PnP OS: Yes/No" changes, etc.?)
And as a correlary to that, if, hypothetically-speaking, XP does switch into some sort of non-prefetched, deterministic, wait-state-based boot process when loading from Hibernation (although that would seem to directly oppose the apparent goal of Hibernation - speed - so I feel it is unlikely), then is there any way to activate that sort of boot mode during normal OS usage, and bring back the deterministic boot-order of W2K? That is, if this feature exists in XP for backwards-compatibility... which I sincerely doubt, mostly because MS spent so much time on XP boot-time optimization work (probably as much time as they did on all of the othe added "fluff" features for the user-shell).
This is actually a real problem with XP for some people, that has been empirically-tested. It causes multiple system-level device-drivers and whatnot, that "hook" certain other things, to occasionally change the order in which they load their hooks, which changes the behaviour of the system. Specifically things like layered software firewalls. (Whether that is a good idea or not in general, I refuse to get into, but suffice to say that some users do that, and it was at least deterministic with respect to installation order with W2K. Not everyone wants to squeeze an extra three seconds out of their OS boot-up times.)
Originally posted by: bsobel
Perhaps it gets some people's ire up, that I dare confront the FUD, but I have a penchant for ranting,
Oh great, and I just answered your other thread about where I work And as much as you say you don't like, I think your doing the same to an extent (especially around the hibernation issue).
Best,
Bill
Perhaps, but I believe all of my statements to be accurate, at least technically. I only kept on about the Hibernation thing as long as you kept bringing it up. But a good discussion nonetheless.
(I am still curious about the hardware enum vs. Hibernation interactions though, that is interesting.)