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."

11 of 152 comments (clear)

  1. Always behind the times... by grub · · Score: 4, Funny


    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,
  2. Let the scheduler algorithm flamewar begin.. by GillBates0 · · Score: 4, Funny

    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
  3. Ordinary users? by MisterFancypants · · Score: 4, Insightful
    "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"

    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.

    1. Re:Ordinary users? by ErichTheWebGuy · · Score: 4, Funny

      parent poster is right. one of my wannabe-geek coworkers saw that and asked me, "doesn't evolution take care of your scheduling needs?" I am not joking. True story.

      --
      bash: rtfm: command not found
  4. nanokernel: scheduler by Doc+Ruby · · Score: 4, Interesting

    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

    1. Re:nanokernel: scheduler by sploo22 · · Score: 4, Informative

      You mean an exokernel?

      --
      Karma: Segmentation fault (tried to dereference a null post)
    2. Re:nanokernel: scheduler by Doc+Ruby · · Score: 4, Informative

      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

  5. Scheduler Development? by Anonymous Coward · · Score: 4, Funny

    I thought everone was using MS project. No?

  6. Re:I hope I'm not alone when I ask... by vadim_t · · Score: 5, Informative

    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.

  7. schedulers as modules by rsd · · Score: 4, Interesting

    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...

  8. Re:who cares by angulion · · Score: 4, Insightful
    Either way---say what you will, but windows has always been more responsive on the desktop.

    And Linux has been more responsive in the server-room. A server doesn't even need a desktop.
    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).

    (What directX equivalent is there on Linux?)

    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?
    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.

    I'm not flaming you---but the article. Users don't give a shit about schedulers if there's no applications with them.

    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.