Slashdot Mirror


Inside the Windows Vista Kernel, Part 2

BuR4N writes "Mark Russinovich takes a look at the Windows Kernel and the changes made in Vista. In this second part he describes the workings of the features SuperFetch, ReadyBoost, ReadyBoot, and ReadyDrive and how they improve system performance."

15 of 290 comments (clear)

  1. Re:ReadyBoost by Lord+Bitman · · Score: 2, Interesting

    This, combined with H-HDD mentioned later on in the article, seems to cancel themselves out.

    --
    -- 'The' Lord and Master Bitman On High, Master Of All
  2. Re:ReadyBoost by atarione · · Score: 2, Interesting

    yeah I saw some ASUS board that had 256MB flash memory onboard for this application (readyboost) reviewed..but I can't remember which model......but I imagine more MB may add this feature as Vista takes off.

    --
    actually I am happy to see you, however that is in fact a banana in my pocket.
  3. Where's the Beef? by Jerf · · Score: 5, Interesting

    With all these performance-improving things, shouldn't performance actually, you know, be improved?

    Many have fallen into the trap of building "intelligent" cache systems that perform worse than the "dumb" cache systems. Remember, every MB of RAM caching an app that you might use is not caching part of the photo that you are editing; caching is subtle work.

    So, as I have not used Vista and have no plans to (I'm with Linux), a question: Can anybody tell me that they put Vista on their computer and things are now noticably faster? I've heard from people with the opposite experience, now I'm soliciting evidence that all these Ready* things actually help people.

    1. Re:Where's the Beef? by Tony+Hoyle · · Score: 4, Interesting

      Another data point.

      Athlon X2, 2GB RAM, Go 7300. Vista in default configuration runs at about 75% of the speed of XP. Switching the 'Ready' crap off gets it up to about 85-90%.

      Power management is unusable - XP 3-3.5 hours, Vista default, 1 hour, Vista with crap off, 2 hours.

    2. Re:Where's the Beef? by HappySqurriel · · Score: 1, Interesting

      I don't run vista so I really don't know, but ...

      I suspect that any performance improvements in Vista were soon eaten up by added overhead elsewhere. Something I've noticed with Windows (since Windows 95) is that with every 'upgrade' Microsoft decides to run more stuff in the background for no real gain and I imagine that vista is no different.

    3. Re:Where's the Beef? by benzapp · · Score: 2, Interesting

      Not entirely true. I have a Dell laptop with a Pentium-M 1800 and 1 gig of ram, I also started using a spare 2 gig SD card for ReadyBoost. The machine is faster with Vista than without, although the weak Intel video card disables all the Aero features.

      It's not as fast as my main system which is similar to the parent poster, but overall on my two machines, Vista is a significant improvement and I think worth the upgrade price.

      --
      I don't read or respond to AC posts
    4. Re:Where's the Beef? by octopus72 · · Score: 2, Interesting

      Gaming problems are probably related to still experimental and less optimised 3D drivers for Vista's new graphic card driver model. 3D drivers for XP by ATI/Nvidia are usually full of nasty hacks, purpose of which is to speed up major gaming benchmarks (3Dmark, Quake, Doom, UT etc.). I guess many of those tricks aren't, well, portable (easily) to a new driver model. Vista can use XP drivers drivers though, but I guess this could work less than optimal.

      As DWM shuts down whenever app locks front buffer (and direct3D games do that), I doubt that compositing is a reason why games perform slower. Another possibility is that scheduler classes (described in first part article) might affect CPU performance of games tweaked to run well with XP scheduling (e.g. I experienced hiccups with PES6).

      Regarding article(s), I must say I'm not that impressed with amount of changes that got in their kernel since XP (except maybe by new driver framework which is a different story). In many areas mentioned in articles, Linux kernel is leaps and bounds ahead (scheduler,MM,IO-areas which saw huge refinements during 2.6 cycle and are constantly being improved). In others it is on-par (or almost here, like with PM or init mechanism). Exception seems to be Ready* stuff, but this is not really "a next big" thing anyway and seems as something that few decent kernel hackers could implement in a month or two. Also Vista now seems to have better graphic driver model (though DRI is closing the gap) and better userspace driver model (except they don't have FUSE equivalent).

  4. Slowing down over time? by HockeyPuck · · Score: 3, Interesting

    I always notice the greatest improvement in speed is when I reinstall XP, then about 9months later it slows down again. (no it's not spyware, filesystem frag etc..). This slowdown phenom. is well documented in windows cirlces.

    Does Vista suffer from this same problem?

  5. Re:Why 'Ready'? by PitaBred · · Score: 5, Interesting

    No seek time. That's the main benefit over a hard drive. If you need lots of data, it's not that great. But if you just need a few bytes, it'll be faster than asking the hard drive. Ask the USB stick for the first few bits of a page, and the hard drive for the rest, and you get the best of both worlds.

    At least, that's how I'd design it if I were much of an engineer ;)

  6. Re:Is this REALLY secure? by TheRaven64 · · Score: 2, Interesting

    For example, where are they storing the encryption key? I would imagine in RAM, in ring-0, so it's lost when you reboot (it's just a cache, so it doesn't matter if it's unrecoverable) and it should be impossible for a userspace process to get at it while the system is running.

    Also consider the CPU cycles required to do the encrypting/decrypting and that this is just one of MANY tasks the OS is doing with encryption-bound services. A modern CPU can execute around 300 million instructions per hard disk seek. AES decrypting a block of data is trivial next to that. This is why ZFS adds a SHA hash to every block; it's a tiny overhead on a modern CPU.
    --
    I am TheRaven on Soylent News
  7. Re:Why 'Ready'? by Cokeisbomb · · Score: 2, Interesting

    the XP in Windows XP was for eXPerience (http://en.wikipedia.org/wiki/Windows_XP).

  8. Re:ReadyBoost by DigitAl56K · · Score: 2, Interesting

    Flash can survive only so many write operations. Normally it's not a practical limitation, but what happens when the OS is constantly doing rw's for caching?

    The last thing I need is to have data corrupted as it moves through a bad flash stick, and is then potentially written back out to the hard drive later.

  9. Re:Why 'Ready'? by mrchaotica · · Score: 2, Interesting

    "USB 2.0 hi-speed" is 60MB/sec, not 10. Although that's still less than your 80+MB/sec figure, it might be reasonable to assume that it's higher than the sustained transfer speed of the SATA drive. Since ReadyBoost (or whatever) uses memory on the order of hundreds or thousands of megabytes while hard drives have caches on the order of one megabyte, ReadyBoost could still provide a significant speedup for reads larger than 8MB but smaller than 2GB.

    Besides, I think the intent is more to have high-speed flash on a fast bus, like on my X60 (which has a SD slot that is not attached through a USB interface, but something else (PCI[e], maybe?) instead. In that case, it conceivably could be faster than the hard drive's burst speed.

    --

    "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

  10. Re:Why 'Ready'? by ratboy666 · · Score: 2, Interesting

    So here I sit, thinking about this...

    I don't think it would be for frequent writes -- that can kill flash. Especially if there is a fixed area for these writes (unless there is a write spreader thingum in the flash).

    Flash does retain information over a power-cycle, and the "seek time" is zero.

    I think I would put commonly used small files on the flash that are NOT written very much. Stuff like the old "CONFIG.SYS" of DOS days. Perhaps application relocation information, and resolved load information (seek to HERE and do a BIG READ).

    I am trying to figure out what kind of improvement I could get. The load information caching may result in a fairly impressive gain (given the DLL and DLL nesting typically used). Small file caching? It depends on application level behaviour. The OS kernel ITSELF should not benefit from these things, "outer" OS layers (GUI) should benefit slightly.

    --
    Just another "Cubible(sic) Joe" 2 17 3061
  11. Re:Why 'Ready'? by ILuvRamen · · Score: 0, Interesting

    And you can't forget how they messed up the other direction. They made the EXACT SAME MISTAKE AS XP! *throws his computer out the window* If you have 3.5 GB of open RAM, it will STILL take tons and tons and tons of extra read/writes on the hard drive and ram to optimize the memory currently in RAM. If you so much as switch between two programs, it will cache some and write it to the hard drive and run AI test cycles on the processor to determine the likelyhood of you coming back to the program and rate it on a 0-7 scale. In fact, that's the only real difference. Now it's harder and slower for windows to decide the priority of memory and it's more likely to predict your actions incorrectly and wastes resources and time in the meantime. If there's more than half the ram open, I say just LEAVE IT ALONE!

    --
    Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'