Slashdot Mirror
Bossa, a Framework for Scheduler Development
Eugenia writes "The recent activity in Linux kernel development caused by the introduction of a new scheduler by Ingo Molnar has emphasized for ordinary Linux users the importance of schedulers in modern operating systems. This article gives you a glimpse of what scheduling development is like by letting you implement your own Linux scheduler thanks to Bossa, a framework for scheduler development."
You mean an exokernel?
Karma: Segmentation fault (tried to dereference a null post)
What the poster meant was that the introduction of the O(1) scheduler, and the benefits to user experience it provided, caused a lot of "ordinary users" to take notice. That doesn't necessarily mean most "ordinary users" know, or even care.
However, for those that do, you'll Soon be able to drop in the latest IO, CPU or 'whatever' scheduler, now being developed independantly from the kernel.
tasks(723) drafts(105) languages(484) examples(29106)
No, those other jobs removed from the nanokernel run as independent apps. We've simplified the architecture, by reducing the inner complexity of the kernel, and moving its functions into the rest of the system. IPC and HW access are the only roles which need unique centralization, even in our "OS" paradigm. That means bugs are easier to identify, with fewer hidden dependencies (they're more overt). And performance is more granular, with less extra functions required to be loaded, and logically considered, to perform a specified task. Better security from the reduced trust among processes and the kernel, with a simpler model for their interoperation.
The kernel is much smaller. The old kernel's functions are distributed in more, optional, dynamically (runtime) includable objects, so they might even be spread among a larger total object population. But that isn't necessary to specific operations, and that can be tuned at runtime, by some of the processes themselves. Just another step down the road away from the monolithic, single-task computer, for increased parallelism and manageability.
--
make install -not war
What a Scheduler is.
> A really distributable system would include only the scheduler in the kernel
No, a kernel doesn't even need to have a scheduler in it. It needs to be able to take instructions to transfer control to another cpu context, and be able to create the necessary page tables, and that's about it.
A scheduler is a part of the OS which decides what process has access to a given resource at a given time. The main scheduler is the process scheduler, which allocates which process gets to use a CPU right now. There's also schedulers for disk access, sending ethernet packets, and anything else that can only be accessed 1 at a time.
I still have more fans than freaks. WTF is wrong with you people?
The mentioning of "API" or "IPC" or "message" (let alone access control!) entirely excludes any exokernels.
Have you turned on DMA for your hard drive? (hdparm -d 1 /dev/hda).
It's the part of the OS that determines what task to run.
The problem is this: You want to run tasks A, B, and C, and need to do it in the most optimal way possible.
The simplest way is FIFO, like say, DOS. If A starts first, then A runs until completion, then B starts. This is bad for many reasons, like that if A gets stuck for any reason nothing gets done, and that while A is waiting for input the free resources can't be used for anything else.
A simple way of multitasking would be simply alternating between A, B and C every fixed interval. But that's not very good either, perhaps B doesn't need to do any processing now, and only wastes time, while C could really use that.
A better way is to do it by priorities, but then you need to find a good way of calculating this priority.
One of the reasons there's so much talk about them is that most become slower when you have more tasks. Most of the simple ones need to examine every running task to determine what should run now, and if you want to launch 10000 processes at once, that's not good. O(1) schedulers are a solution for that, because they use algorithms that always take the same amount of time to execute, irregardless of whether there's 3 or 10000 tasks. That doesn't mean a simpler scheduler wouldn't work faster for 10 tasks, though.
The other problem is how to determine how to distribute CPU time. Say, for servers you mostly want fast and fair3o determine which processes are interactive, and which are on the background and won't mind some interruption.
Speeding up Linux Using hdparm
Reason is the Path to God - Anon