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,
...they said this story doesn't belong on the front page.
no really
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?
What the hell is a scheduler?
Like this is anything new... I had a Casio musical keyboard in like the '80s with a Bossa Nova key.
My condolences to all who do work on this part of the OS.
what the hell
I hope you are trying to be funny
haven't read the article but am damn sure this isn't like the 'Schedule tasks' or the simple 'Prioritise Background services over Applications' option that you find in windows
Each time you reboot for a kernel upgrade, academics have proven Linux wrong.
Are we back to "better scheduling?" ... I thought that was a mainframe technology struggle...........
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
Taco, it just struck me that the mod system is seriously remiss in not having a way to mod a post as being "Eloquent". It's really something different from "Interesting", isn't it.
(It would also be nice to be able to search comments by mod-type.)
I wish I could use it here:
"You haven't made the kernel smaller, you've just pulled a part of it out because you think it'd be cool to hold its beating heart in your hand while it still runs."
10 penguins for anyone who can suggest a scheduler that taxes the stupid newbie programs with
while(1);
(/me too is a newbie)
Europe Reluctantly Deciding It Has Less Time for Time Off
New York Times
By MARK LANDLER
FRANKFURT, July 6 -- For Michael Stahl, a technician at a cordless telephone factory in the town of Bocholt, summer is usually a carefree season of long evenings in his garden and even longer vacations. His toughest choice is where to take his wife and three children on their annual camping trip: Italy and Croatia are on this year's itinerary.
Two weeks ago, however, Mr. Stahl got a rude jolt, when his union signed a contract with his employer, Siemens, to extend the workweek at the Bocholt plant to 40 hours from 35. Weekly pay remains the same. The new contract also scraps the annual bonuses every employee receives to help pay for vacations and Christmas expenses.
"I'll have to make do with less," Mr. Stahl said with a sigh. "Of course, the family will come off the worst."
After nearly 27 years at Siemens, Mr. Stahl, 42, feels he has no choice but to put in the extra time. Like millions of his fellow citizens, he is struggling to accept the stark new reality of life in a global economy: Germans are having to work longer hours.
And not just Germans. The French, who in 2000 trimmed their workweek to 35 hours in hopes of generating more jobs, are now talking about lengthening it again, worried that the shorter hours are hurting the economy. In Britain, more than a fifth of the labor force, according to a 2002 study, works longer than the European Union's mandated limit of 48 hours a week.
Europe's long siesta, it seems, has finally reached its limit -- a victim of chronic economic stagnation, deteriorating public finances and competition from low-wage countries in the enlarged European Union and in Asia. Most important, many Europeans now believe that shorter hours, once seen as a way of spreading work among more people, have done little to ease unemployment.
"We have created a leisure society, while the Americans have created a work society," said Klaus F. Zimmermann, the president of the German Institute for Economic Research in Berlin. "But our model does not work anymore. We are in the process of rethinking it."
From the 1970's until recently, Europe followed a philosophy of less is more when it came to labor, with the result that Europeans work an average of 10 percent fewer hours a year than Americans. Germans, with the lightest schedule, work about 18 percent fewer hours.
The job creation argument went hand in hand with the greater social premium that Europeans place on leisure. In the land of the four o'clock rush hour and the monthlong summer holiday, it does really seem, as the cliché goes, that Europeans work to live, while Americans live to work.
Siemens, however, upset that conventional wisdom by threatening to move production of cordless and cellular phones to Hungary, where salaries are a fraction of those in Germany. That would have cost about 2,000 jobs in a country that, with a jobless rate of 10.3 percent, can ill afford it.
"It's about lowering labor costs," said Peter Gottal, a spokesman for Siemens, which is based in Munich. "Where we are in a global competition, 35 hours are no longer feasible. We just need more hours."
Siemens and its union say that the contract is not a template for the rest of German industry, but it is being viewed that way. The company, one of Germany's largest employers, is negotiating wages at five other factories, and it may demand some of the same concessions, including different work hours, that it received at Bocholt.
A longer workweek also looms for assembly line workers at the Mercedes-Benz plant in Sindelfingen, in Southwestern Germany. There, the company wants to curtail breaks during the workday.
Mercedes has not threatened to abandon Germany. But auto workers shivered recently when Opel, which is owned by General Motors, announced that it would assemble a compact minivan at its plant in Gliwice, Poland, passing over its main factory outside Frankfurt, which h
Ummm, you *do* realize that we're not talking about scheduling like the Windows Task Scheduler right?
Anthony Papillion
Advanced Data Concepts, Inc.
"Quality Custom Software and IT Services"
The Bossa DSL is more constrained than C or C++ in that, for example, pointers (known for being the cause of many bugs) are absent and infinite loops can't be defined.
The part about infinite loops would be interesting as you can always shoot yourself in the foot in a zillion ways
For eg: a stupid like me might write something like
do blahblahblah while f(pid1) is less than f(pid2)
where f(x) isn't effected by blahblahblah() and f(x) is less than f(y) when x is less than y
This guy gets it. MisterFancypants is just looking for excuses to complain. The article never implied that ordinary users should care about, or even know about, scheduling. What it says is that scheduling algorithms are important for ordinary users. There is a world of difference between these two statements.
While the NT kernel does have a kernel scheduler, just like all commercial OSes, but it is universally regarded as the bigget weakness in Windows and one of Linux's strengths. Linux has an O(1) scheduler which has been adopted by other *NIXs but the NT scheduler still has problems with more than 800 processes. Which is very poor...
"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.
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...
*cue ob jokes*
Either way---say what you will, but windows has always been more responsive on the desktop. (What directX equivalent is there on Linux?) If Linux developers don't stop diddling around with something that was solved years ago, Linux will just go away. Linux doesn't even have a program that can do half of what programs like dreamweaver can do. For the developer, what app is as integrated as Visual Studio? KDevelop? Pshaw. I'm not flaming you---but the article. Users don't give a shit about schedulers if there's no applications with them.
With Real Time Java a programmer can request explicit timing guarantees, by direct interaction with the scheduler. Just derive your threads from javax.realtime.RealtimeThread (if it is implemented in your version of Java :)
It frightens me when so many "programmers" or "software engineers" seem to be frightened by or even oblivious to concurrency problems. This should be a fundamental skill anyone writing software should have. Are there schools out there not teaching these basic concepts somewhere in their degree program?
Sorry, but the name Bossa immediately invokes thoughts of Jar Jar Binks, as in : "Yousa Bossa. Jar Jar Binks thinka massa need a process."
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.
I think I'll take the reboots every few years over the 20-30% "minimal" performance loss that comes along with your academic microkernel tyvm.
In a way it is... in the same way that writing a custom iptables script is like checking the box to enable software firewall on this connection in windows ;)
In my experience semaphore programming can get really really complicated, and if they didn't have to, I'm sure a lot of other programmers out there would rather not work with them either. I'll leave that up to the really smart people. :-)
Chevy Nova?
whatever lunix doesnt have strengths unless you call buttsex a strength am i rite
-just do the scheduling outside the main kernel and CPU and do it with a separate embedded OS/processor? Too much latency? Dual core maybe then?
I hope I coule use Generate algorithms to find out the best scheduler for the system.
Any errors that occur, all that will be able to be said is, "Blame it on the Bossa Nova." (Long groan follows.)
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
Each time you reboot for a kernel upgrade, academics have proven Linux wrong.
OK so explain Windows NT.
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
Uh, even micro-kernel systems have kernels; they're just very small. If you wanted to upgrade the kernel in a micro-kernel system, you'd likely need to reboot your machine. It is true that you can replace the parts of a microkernel which is outside the kernel without a reboot E.g. you can upgrade the filesystem without restarting the kernel itself, so there is some gain in micro-kernel designs.
There are schemes that allow you to change a running kernel without a reboot, but they can apply equally to both monolithic and micro kernels.
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.
I'm a bit confused... Is this about scheduling??
They will never know the simple pleasure of a monkey knife fight
There is a link below each post, called "Reply to This". If you click on it, you can write a reply which is linked to the post you are replying too and is nested properly. Please use it.
I will agree with you there. Concurrency problems can get very complicated. So long as you are aware of the problem you've won half the battle. From your past experience you should be well prepared to handle future concurrency problems that arise.
The smaller, more "agile" nanokernel could offer better interrupt handling and more granular CPU/memory accesses, therefore keeping more accurately on a realtime track. But for high-throughput realtime signal processing, another computing model is probably more appropriate: truly parallel logic arrays.
True parallelism means the that clock rates don't have to be jacked up to millions of times the rate of the events being processed (eg. 100s of GHz for 10s of KHz audio), just to ensure that thousands of thousands of instructions might be performed on hundreds of sequential tasks required to appear simultaneous. Routers already use FPGAs to handle these kinds of tasks, running at 100s of MHz on 10s of MHz of packets (eg. OC-192 routing). Once software development tools are high-level enough to allow many music-literate programmers write studio software, some winners will float to the top. The recent development of uCLinux for the MicroBlaze "soft processor" running on a Xilinx FPGA, with extra gates to spare, offers a really exciting platform for the transition. Why not get started porting your favoring Linux sound tools to uC/MB, and strike up the band?
--
make install -not war
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...
My keyboads not woking popely.