Slashdot Mirror

← Back to Stories (view on slashdot.org)

Bossa, a Framework for Scheduler Development

Posted by CmdrTaco on from the one-for-the-techies dept.

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

8 of 152 comments (clear)

  1. 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 Ignignot · · Score: 2, Interesting

      And you've just created the need for a "sub-kernel" which would do your actual work. We're talking more complexity. More bugs. Less performance. Less security. 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.

      --
      I submitted this story last night, and it didn't get posted.
    2. Re:nanokernel: scheduler by sql*kitten · · Score: 3, Interesting

      You are describing the IBM AS/400.

  2. I hope I'm not alone when I ask... by Anonymous Coward · · Score: 1, Interesting

    What the hell is a scheduler?

  3. Interrupts by LordMyren · · Score: 3, Interesting

    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

  4. Re:eeek (OT) by slashjames · · Score: 2, Interesting
    Working with semaphores and locks... *shudder* keep the bad man away!!

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

  6. Impact of scheduling on threads by ThePhin · · Score: 3, Interesting

    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:

    The 2.6 Linux kernels changed the behavior of sched_yield() in a way that causes the unfairness you observed. Other threaded applications are affected, including Open Office (!). My belief is that it's really a bug in 2.6 kernels and that the new behavior of sched_yield(), while technically conformant to the POSIX specs, lowers the quality of implementation quite a lot.

    (I seem to remember from my LinuxThreads development days that this isn't the first time the kernel developers broke sched_yield(), then realized their error.)

    The question I'm currently investigating is whether the call to sched_yield() can be omitted, as it's just a scheduling hint. Initial experiments suggested that this would hurt fairness (in Caml thread scheduling) quite a lot on all platforms other than Linux 2.6. More careful experiments that I'm currently conducting suggest that it might not be so bad. One can also play games where sched_yield() isn't called if there are no other Caml threads waiting for the global Caml mutex.

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