Slashdot Mirror
Inside the Windows Vista Kernel
Reader trparky recommends an article on Technet (which, be warned, is rather chaotically formatted). Mark Russinovich, whose company Winternals Software was recently bought by Microsoft, has published the first of a series of articles on what's new in the Vista kernel. Russinovich writes: "In this issue, I'll look at changes in the areas of processes and threads, and in I/O. Future installments will cover memory management, startup and shutdown, reliability and recovery, and security. The scope of this article comprises changes to the Windows Vista kernel only, specifically Ntoskrnl.exe and its closely associated components. Please remember that there are many other significant changes in Windows Vista that fall outside the kernel proper and therefore won't be covered."
Yet another (promised?) feature they could not deliver.
??? This is in Vista
thought for a second that they required admin access to activate MMCSS; but upon a second reading, it looks like they've merely reimplemented nice with some kind of setuid root service.
"nice" as you call it has been in NT since its conception.
He's talking about multimedia specific scheduling related to I/O operations here, you might want to read this whole document a 3rd time, he's not talking about "regular" kernel scheduling of threads/processes, he's talking about scheduling based on I/O needs which is a whole different beast.
Cancelling I/O has been in Windows for long, "just" not always done properly. I have seen similar issues while killing processes in other OSes where they are stuck in some I/O. One reason for why this happens more frequently in Windows (in addition to bad drivers/a complicated driver model) is the fact that asynchronous I/O is so common. That way, you might not see the that the IO got stuck until you try to kill the process.
The symlink(2) manpage mentions that they're also known as "soft links", as opposed to the hard links created by link(2). It's not a very common usage, though.
Ita erat quando hic adveni.
True in theory, but Universities can license the source code of the windows kernel for academic purposes:
i censing/researchkernel.mspx
http://www.microsoft.com/resources/sharedsource/L
cfq/ionice is for reads only. "Due to the complex path writes take to get to the io scheduler there is no ionice support for writes yes so they are all treated equally." It'll happen...
Tired of free ipod spam sigs? Opt ou
`` I have seen similar issues while killing processes in other OSes where they are stuck in some I/O.''
Oh, the horrors! I've had this happen to me many times, as well, especially on Linux. Not even a kill -9 would get rid of the wedged process. Why is there even such a thing as "non-interruptible sleep"? If I don't need the process anymore, I should be able to get rid of it no matter what.
And wedged drivers, too. I think you can still see this for yourself by doing I/O with some USB device, and then yanking it out while the I/O is in progress. You get at least one process that you can't kill (I guess the comatose state causes ethical issues), and probably a driver you can't unload (although maybe new kernels allow you to do that). If you're "lucky", you get a whole lot of hardware devices that you can't use anymore, and any program that tries to gets into the dreaded D state.
Please correct me if I got my facts wrong.
Yes. A round robin scheduler, which runs every task for exactly 2 clock ticks except for foreground tasks which are run for 6 (or is this an XP improvement ?) - assuming there's no interrupts occurring during those ticks, of course - and not paying any attention to whether the task is IO- or CPU-bound. It performs absolutely shitty if you have anything heavy running in the background (say, POV-Ray rendering an image while you try to browse the Net). Praising that to be "O(1) scheduler" is about the same as calling the Goatse picture "art": sure, it may be technically true, but...
What Linux was praised was getting a scheduler that handles 40 priority levels, real-time tasks, and multiple CPUs (500+, in some cases) while retaining both interactivity and high throughput, and doing all this in O(1) time. No version of Windows has ever gotten even close.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.