OSDev.org

d11in wrote: now the scheduler knows the tree (that's what the program will do/ the scheduler knwows exactly when a program requires an io operation or something other).

The scheduler cannot know this only with non-branching code. With branches, it cannot know which branch to take before it has actually done the calculation - as Pype already mentioned.

Consider that one of the most important features of a scheduler - aside from fairness and efficiency - is scaleability. With every year, the number of processes on an average system is increasing. (That's what's eating those GHz!) The Linux kernel made a very important step in finally catching up with "pro" operating systems in that it now implements a scheduler that is O(1) - that means, the scheduler takes constant time to select the next process to schedule - regardless of the number of processes waiting to be scheduled.

Sure, you can come up with a really "smart" scheduler that really kicks butt in your tests. But how does all that "smartness" scale once there are thousands of processes? Do you really want to look ahead what each process is going to do next?

Candy wrote:
PPS: Windows (2k, xp) doesn't keep up at 12x cdrom burning on a 1200mhz duron with dedicated IDE channel... or is that just me?

That's just you. Something similar (don't remember exact clocks) burns with 52% just fine here. So I'd check that DMA works

Solar wrote:

d11in wrote: now the scheduler knows the tree (that's what the program will do/ the scheduler knwows exactly when a program requires an io operation or something other).

Sure, you can come up with a really "smart" scheduler that really kicks butt in your tests. But how does all that "smartness" scale once there are thousands of processes? Do you really want to look ahead what each process is going to do next?

Also, if you calculate what each process will do and then pick the best one / do those things before the process does them, youe slowing down the system. You can only speed things up if the future events can be predicted quite accurately, and even then only in the most optimal cases. Examples: predicting a process will want the pages its eip and esp point to, predicting a process will again run through the same pages etc.

In other words, you can only predict the near-obvious.

In all other cases it better to just run it and stumble.

Same goes for compression, you can only compress a data stream with *some* form of redundancy. It is provably impossible to compress a random data stream. Of course some US dude didn't think it through and filed for a patent ::)

* he actually holds the patent...