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."
Most commodity computers can only run one process at a time
Ha, with Longhorn 2010XP+++ and Office 2012 I'll be able to have two Clippys simultaneously! Take that, hippy!
Trolling is a art,
I see your FIFO scheduler and raise you my Elevator algorithm!
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
I know some people will take this as flamebait, but I honestly don't mean it to be. However, as long as Linux is in a state where developers think that "ordinary Linux users" have to even care what a scheduler is, Linux will be a failure for mainstream desktop usage.
Users don't care about OS internals. Don't send them to a page explaining OS scheduling, just tell them "All new Linux makes your applications more responsive!". That's all they want to hear.
Seriously.
A really distributable system would include only the scheduler in the kernel, with an "outer" layer of secure (crypto signed, sealed and delivered) APIs for submitting process and data requests, and an "inner" core for hardware access, including CPU, data (storage/network such as ethernet, USB, IDE, RAM, BIOS ROM, etc) and presentation (monitors, keyboards, mice, soundcards, printers, etc). Such a nanokernel would be tiny, highly efficient, and mix/matchable with many other apps and OS'es. Privileges would be part of a comprehensive security model, with IPC filtered through access control, whether within a single memory segment, LAN, or WAN. All domains would be virtualized. And such symmetry and simplicity would set the stage for flexible inter-kernel load balancing and failover.
We're talking open-ended scalability. Security. Performance. Reliability. The OS is no longer just a privileged app, but a smaller, more focused critter, serving apps rather than being served by them. With this new scheduler framework, let a billion nanokernels bloom.
--
make install -not war
I thought everone was using MS project. No?
Depends how you pronounce it. If you pronounce it properly then it a vital part of the OS determining how the various running processes interact with the system, resources and each other. If you use the American pronunciation then its something KDE are probably working on to organise your time.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
What a Scheduler is.
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?
I hope this succeeds, then gets improved upon in a second version. How cool would it be to be a part of the next project called... "Bossa Nova"?
Small potatoes make the steak look bigger.
I have a sneaking support its poor interrupt handling which makes my ALSA skip like Riverdance every time i start a file copy in mid song.
Even buffering the full song, it still skips. I've tried XMMS, moosic, mpg321. I've sought ever high priority trick i can. No matter what I try, start that file copy and WHAMO, instant pain and suffering.
Myren
10 penguins for anyone who can suggest a scheduler that taxes the stupid newbie programs with
while(1);
(/me too is a newbie)
The scheduler is the person on your project team who, after each week's schedule slips, tapes together the latest updated Gantt chart printouts into long banners and hangs them the walls.
Just remember that it's those semaphores, mutexes, and locks that allow multi-threaded applications work. A class that is supposed to be "thread safe" but isn't will make your life rather... interesting.
"Working with semaphores and locks... *shudder* keep the bad man away!!"8 0&cid=964 7043
http://slashdot.org/comments.pl?sid=1138
Actually, it's quite interesting. It forces you to conceptualize with a certain kind of rigor, and to code with particular vigilance for potential deadlocks, race-conditions, and mis-serialization of resource-updates.
I can't tell you the number of times that I've read or listened to a description of a design or architecture, and immediately said "uh-oh", to the surprise and dismay of developers who really should know better.
In a time of increasing processor parallelism, this is a skill-set which must be mastered by anyone who truly aspires to become (or remain) a serious professional-level developer. It's not just for kernel-hackers.
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.
Using a plugin^Mmodule interface to load schedulers at runtime wouldn't generate
a performance impact in the scheduler? (as opposed to have the scheduler compiled
inside the kernel).
I AFAIK, the scheduler has to be as compact (optimized) as possicible to reside as long as possible
in the cpu's cache. This way it can check the memory pages map as fast as possible to [de]allocate,
switch process as fast as possible.
Using a module scheduler, wouldn't make it have to derreference each function address each time
each function is called?
And probably sometimes derreferencing derreferences few times to get the correct address?
Couldn't this hurt performance?
I agree that loading an efficient scheduler to handle a situation better than the defalt scheduller would
compensate for that, but still...
And Linux has been more responsive in the server-room. A server doesn't even need a desktop.
(What directX equivalent is there on Linux?)A desktop user like you might not care if your scheduler degrades after you have 800 processes running, but I can assure you people dealing with large server systems does.
Windows is in large part more responsive on the desktop since it is in part intergrated into the kernel - the downside being that what would be a application crash can bring down the whole OS. Also you have less privilege separation. (windows desktop is "unsafe" area, but that is another story).
OpenGL, SDL, OpenAL for starters. Guess what they all can do that DirectX can't?! Yepp, run on different systems and architectures, be it Linux, Windows or a Mac.
If Linux developers don't stop diddling around with something that was solved years ago, Linux will just go away.Linux developer base is quite large and the developers like to "diddle" around to find the best/most effective solution, not the one that takes the least amount of time to make, like it often tends to be when deadlines are pushed in companies.
Linux doesn't even have a program that can do half of what programs like dreamweaver can do.I admit that there is nothing quite like dreamweaver for Linux, but I'm convinced that Quanta can do more than half. :P Anyway, as Linux gets more acceptance, programs like Dreamweaver will eventually be ported.. what will you say then?
For the developer, what app is as integrated as Visual Studio? KDevelop? Pshaw.Are there any development tools that is more restricted to one platform and project management than VS?
I'm not flaming you---but the article. Users don't give a shit about schedulers if there's no applications with them.KDevelop and Anjuta might not be as integrated, but they can use CVS, SubVersion etc. and compile on Linux even for Windows (or the other way around). Oh, and they are free.
No, not at all :P
You know, there are alot of people that acctually are interested in kernel-schedulers, allthough they do not tend to be your average desktop user.
More over, one place where schedulers matter most, ie. in servers, there is absolutely no shortage of applications on Linux.. I'd more like to say there is a shortage of applications in this are for Windows, if anything.
Xavier Leroy is one of the authors of Ocaml, an efficient (within 2x of C) variant of the ML functional programming language. In the Caml-list mailing list recently, he had this to say about scheduling:
So at least one class of user is forced to be aware of the scheduler, to refer to another poster's assertion that users shouldn't even need to know...