Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Con Kolivas Returns, With a Desktop-Oriented Linux Scheduler

timothy posted more than 4 years ago | from the dare-not-speak-its-name dept.

Programming 333

myvirtualid writes "Con Kolivas has done what he swore never to do: returned to the Linux kernel and written a new — and, according to him — waaay better scheduler for the desktop environment. In fact, BFS appears to outperform existing schedulers right up until one hits a 16-CPU machine, at which point he guesses performance would degrade somewhat. According to Kolivas, BFS 'was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. i.e. [sic] it is a desktop orientated scheduler, with extremely low latencies for excellent interactivity by design rather than 'calculated,' with rigid fairness, nice priority distribution and extreme scalability within normal load levels.'"

cancel ×

333 comments

BFS is the Brain Fuck Scheduler. (5, Interesting)

Anonymous Coward | more than 4 years ago | (#29330037)

Why would the summary omit this precious bit of information?

Re:BFS is the Brain Fuck Scheduler. (4, Informative)

Fizzl (209397) | more than 4 years ago | (#29330055)

from the dare-not-speak-its-name dept.

Re:BFS is the Brain Fuck Scheduler. (4, Funny)

Swizec (978239) | more than 4 years ago | (#29330109)

Great, now when someone mentions BFS I won't be able to just assume Breadth First Search.

Another one for the Geeks-are-great-at-naming-things wall.

Re:BFS is the Brain Fuck Scheduler. (2, Interesting)

Jurily (900488) | more than 4 years ago | (#29330477)

Another one for the Geeks-are-great-at-naming-things wall.

All the TLAs are taken anyway. As always, you'll have to look at the context.

Re:BFS is the Brain Fuck Scheduler. (0)

Anonymous Coward | more than 4 years ago | (#29330083)

You looked at goatse [goatse.fr] and you liked it.

Re:BFS is the Brain Fuck Scheduler. (1, Funny)

Anonymous Coward | more than 4 years ago | (#29330147)

You looked at goatse and you liked it.

You know, I think I can see his brain right up at the end.

great news (5, Interesting)

amn108 (1231606) | more than 4 years ago | (#29330045)

Great news :-) Now, will the kernel people with Mr. Torvalds at their head, restart the whole debate on pluggable schedulers. Since his scheduler, as he says, degrades beyond 16 CPUs, better options already exists for servers where I am guessing CFS is used. So, he may be back, but the road ahead is still as steep?

Re:great news (5, Insightful)

s4m7 (519684) | more than 4 years ago | (#29330235)

I think that's only going to be a good thing, because IMO the arguments against pluggable schedulers are weak. "we need the few people working on this to just make the core better for ALL CASES" is about the most valid i've heard, but linux is too broadly applied to force it to meet all cases. realtime, embedded, servers, desktop: i just don't think one scheduler can be shoehorned to maximize performance for all those. You wind up with a crippled scheduler that really only achieves maximum performance in at most one of those four domains. And the question of there being enough developer minds working on it? you can bet that more commercial enterprise will start throwing money at it when they can customize it for their domain.

It's like the dynamic syscall argument in a way. without dynamic syscalls, the argument goes, all the 'fringe functionality' people have to think harder and have to integrate their stuff into the current syscalls/drivers/subsystems. (apologies ingo) however, without dynamic syscalls, all the "middle of the road" functionality people like hardware manufacturers, are unwilling to release drivers that they essentially have to ask customers to compile as a supported option.

Both, IMO are cases of cutting off your leg to spite your foot.

Re:great news (1)

amn108 (1231606) | more than 4 years ago | (#29330281)

I agree. Linux is too large (in the classic meaning of the english word) to run on a single scheduler. But then again, what is a _single_ scheduler? If it means a facility that can plug and unplug schedulers at runtime, let us say switch between CFS (or something even more server oriented) and BFS as it detects server-desktop border patterns, then I guess both Mr. Torvalds and Mr. Kolivas are happy. And users are happy too. The rigid unexplained reason that "we only need ONE scheduler, period." however puts an effective stop to the strategy. If the scheduler cannot be plugged in, i. e. statically linked, mainline kernel will stay with CFS, which it will, because the maintainers will not merge pluggable scheduler facility. Well, we will have to wait and see how this turns out. As a GNU/Linux desktop user, I care.

Re:great news (5, Insightful)

MrNaz (730548) | more than 4 years ago | (#29330313)

I think anyone who cares and knows anything about this debate is hoping Linus sees the light and allows work to begin on pluggable schedulers. There are no definitive arguments against having pluggable schedulers, and plenty of formidable ones for them. I never really understood Linus' handling of Con in the past, I really hope that, this time round, the new BFS is given a fair assessment, and if it's found to be better under desktop use patterns, adopted for use in desktop distros.

The idea that the Nokia N900 smartphone uses the same process scheduler as my now-dated laptop as well as my 8 core server is just silly.

Re:great news (1)

M. Baranczak (726671) | more than 4 years ago | (#29330617)

Does it even need to be a run-time option? A single installation will always run on the same hardware, more or less, so what's the point? Just make it a compile-time setting. Distros can decide which scheduler is right for them, or offer a choice of kernels with either one or the other.

Re:great news (1)

Jurily (900488) | more than 4 years ago | (#29330739)

but linux is too broadly applied to force it to meet all cases. realtime, embedded, servers, desktop: i just don't think one scheduler can be shoehorned to maximize performance for all those.

I thought scalability was the main strength of Linux as an OS. Perhaps it's time we did the same with the kernel. Just as you don't need CUPS if you don't have a printer, you don't need a scheduler scaling to 2^32 CPUs for a laptop.

Re:great news (1)

rnws (554280) | more than 4 years ago | (#29330581)

"better options already exists for servers where I am guessing CFS is used." Well, that depends on your workload (which is the thrust of the debate). With one of the HPC products I regularly work with, we have a best-practice of using the noop scheduler instead of cfs - this tiny tweak alone will see at least a 30% improvement in our I/O performance (which is nothing to be sneezed at when we're moving ~700MB/s). Being able to have pluggable schedulers is great because Linux can be all things to all people and it does make sense to have options (lets not go crazy here - too much choice can also be a bad thing). People talk about the difference between Linux on netbooks and servers for example but even in the "server" space there is VAST difference between small business file & print, clustered Oracle or scientific data acquisition workloads. I too hope that this debate doesn't go away and also hope that it doesn't become as heated and personal as in the past so that we can all benefit from a selection of good ideas.

Glory! (5, Interesting)

CAIMLAS (41445) | more than 4 years ago | (#29330067)

May I be the first to say "amen"? I've been very dissatisfied with the 2.6 kernel and its schedulers on the desktop, CFS in particular. CFS seems entirely braindead for desktop use compared to the older schedulers in 2.4 and yes, even 2.2.

A desktop machine needs to be, first and foremost, responsive. If it isn't, it's comparable to the cursor freezing and input taking several seconds to appear: on today's hardware, one might start to think "hey, did it freeze on me?" - completely unacceptable.

Maybe it can be chalked up to the non-priority of X and video at the kernel level; I don't know. Whatever it is, it used to be better, on very pathetic (133MHz) hardware, while doing a lot more (and when such hardware was not all that powerful anymore, as well).

My question is: is it in the kernel tree yet? Is this that 2.6.31 scheduler change I heard about earlier yesterday, or is it something Completely Different?

Oh yeah, and which other scheduler's, if any, did this guy write?

Re:Glory! (5, Interesting)

kav2k (1545689) | more than 4 years ago | (#29330093)

Citing the FAQ:

Are you looking at getting this into mainline?

LOL.

No really, are you?

LOL.

Really really, are you?

No. They would be crazy to use this scheduler anyway since it won't scale to
their 4096 cpu machines. The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter. Besides, apparently I'm a bad
maintainer, which makes sense since for some reason I seem to want to have
a career, a life, raise a family with kids and have hobbies, all of which
have nothing to do with linux.

Re:Glory! (5, Insightful)

BiggerIsBetter (682164) | more than 4 years ago | (#29330175)

No. They would be crazy to use this scheduler anyway since it won't scale to
their 4096 cpu machines. The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter. Besides, apparently I'm a bad
maintainer, which makes sense since for some reason I seem to want to have
a career, a life, raise a family with kids and have hobbies, all of which
have nothing to do with linux.

Which is not to say that it might not find it's way into the Ubuntu Desktop mainline patchset, for example. Sure it might not make sense for the mainline kernel, but it surely makes sense for a user focused distro like Ubuntu - they already have patched base and server kernels, so why not a genuine desktop targeted kernel?

Re:Glory! (5, Informative)

Hurricane78 (562437) | more than 4 years ago | (#29330541)

What is that? You don't have the choice of scheduler in your kernel? I'm using the Zen sources [zen-sources.org] , and I get to choose between least half a dozen schedulers, including other settings. I am certain that this scheduler will make it into that patchset, and that I will enable it, as soon as zen-sources-2.6.31 get installed on my system.

After all this is Linux! Not some one-company-one-kernel monoculture!

Re:Glory! (1)

solevita (967690) | more than 4 years ago | (#29330559)

Not only Ubuntu, but what about Openmoko, Maemo, Android, OLPC et al? Ok, we're probably not going to see patched Android kernels, but there seems like a lot of projects that could benefit from this, if it's as good as we're told it is.

Re:Glory! (1)

AleBaba (1566049) | more than 4 years ago | (#29330449)

all of which have nothing to do with linux.

Ahh, and I thought his children were penguins and he was sitting in his room all day and night eating pizza and flaming people on lkml. Well, I guess I'll have to revise my image of kernel hackers then...

Re:Glory! (4, Informative)

Trepidity (597) | more than 4 years ago | (#29330111)

My question is: is it in the kernel tree yet? Is this that 2.6.31 scheduler change I heard about earlier yesterday, or is it something Completely Different?

No, and probably won't ever be, though perhaps some ideas will be borrowed.

From his FAQ:

Are you looking at getting this into mainline?

LOL.

No really, are you?

LOL.

Really really, are you?

No. They would be crazy to use this scheduler anyway since it won't scale to
their 4096 cpu machines. The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter. Besides, apparently I'm a bad
maintainer, which makes sense since for some reason I seem to want to have
a career, a life, raise a family with kids and have hobbies, all of which
have nothing to do with linux.

Can it be made to scale to 4096 CPUs?

Sure I guess you could run one runqueue per CPU package instead of a global
one and so on, but I have no intention whatsoever at doing that because it
will compromise the performance where *I* care.

The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS [kerneltrap.org] over Kolivas's own RSDL, in particular at least one LKML poster suggesting that, all else being equal, it'd be better to merge Molnar's code, as he was more likely to be a reliable maintainer (Molnar's more tied into the workings of the mainline kernel development/merging/etc.).

Re:Glory! (2, Interesting)

MichaelSmith (789609) | more than 4 years ago | (#29330179)

The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS [kerneltrap.org] over Kolivas's own RSDL

Yeah but Con just didn't give the impression that he intended to be around to support his code. He is an anaesthetist. Software is a hobby which he could give up whenever he wants to. I think that is very different from somebody who is doing software for their career.

Re:Glory! (4, Informative)

Trepidity (597) | more than 4 years ago | (#29330211)

Yeah, that makes sense, but he seems to have taken it personally. It sounds like part of it stems from his feeling [lkml.org] that Molnar unnecessarily wrote a replacement using his ideas and got credit for it, instead of helping out to turn one of Kolivas's fair-scheduling proposals into something that could be merged. Though from what I can tell Molnar's replies are all pretty friendly, and he seemed keen to provide appropriate credit.

Re:Glory! (4, Insightful)

mwvdlee (775178) | more than 4 years ago | (#29330395)

The whole point is moot. Relying on a single maintainer is just plain stupid. "All things being equal" they should choose the code which OTHER people can maintain easier.

That has NEVER been the goal (0)

Anonymous Coward | more than 4 years ago | (#29330603)

If they really wanted maintainability they would have changed to microkernel architecture years ago.

Re:Glory! (0)

Anonymous Coward | more than 4 years ago | (#29330415)

Software is a hobby which he could give up whenever he wants to.

You realize this is how most of the linux world works right?

Re:Glory! (1)

MichaelSmith (789609) | more than 4 years ago | (#29330441)

Software is a hobby which he could give up whenever he wants to.

You realize this is how most of the linux world works right?

I am not sure it is how the kernel developers work. Think about it: it is likely that Con Kolivas has never once used an operating system other than windows in his working environment. He uses linux at home, in his spare time. He may never have seen Linux used in a large scale production environment.

Re:Glory! (1)

AleBaba (1566049) | more than 4 years ago | (#29330485)

...he could give up whenever he wants to.

That's always something that can happen. For instance ReiserFS made it's way into the kernel and turned out to be a pain in the ass to maintain.

Re:Glory! (1)

gabebear (251933) | more than 4 years ago | (#29330711)

You do have to give Hans Reiser credit for putting the work in to maintain his code... Reiser4 was/is one of the most cutting edge file-systems available. If he hadn't murdered his wife we might not even be looking to EXT4 and BTRFS.

Re:Glory! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29330709)

Shuttleworth just doesn't give the impression that he intends to be around to support Ubuntu. He is a business man. Ubuntu is a hobby which he could give up whenever he wants to (proof being, Canonical doesn't make money and Shuttleworth doesn't think it can make money anyway, according to his own words).
That doesn't prevent people to use Ubuntu, but that should...

Re:Glory! (0)

mvdwege (243851) | more than 4 years ago | (#29330311)

I would say that Con's FAQ entries demonstrate exactly that Linus was right. That is not the attitude of a reliable maintainer. In fact, the whole rant sounds like a teenager with a chip on his shoulder. And given that Con is supposed to be a mature professional, that says a lot.

Of course, there is also the fact that Con and his fanbois didn't back up their position with benchmarks in the entire CK scheduler flamewar, instead relying on 'it just feels faster' subjective judgments.

I say, let him play in his little sandbox. If there's good ideas in there, they'll get lifted out. If this is yet another episode of the 'Con Kolivas is great!' show, it'll disappear again like last time.

Mart

Re:Glory! (0)

Anonymous Coward | more than 4 years ago | (#29330475)

The attitude of a reliable maintainer is to take all the abuse Linus throws at you, whether he's right or wrong.

Re:Glory! (1)

Progman3K (515744) | more than 4 years ago | (#29330759)

I would say that Con's FAQ entries demonstrate exactly that Linus was right. That is not the attitude of a reliable maintainer. In fact, the whole rant sounds like a teenager with a chip on his shoulder. And given that Con is supposed to be a mature professional, that says a lot.

You're making too much out of it.
The whole idea of Linux is that you can hack it.
Con is actually doing science; he developed a theory of operation, wrote a kernel around it and now it's possible for others to develop more ideas and research into the problems he was trying to address.

Re:Glory! (5, Informative)

kav2k (1545689) | more than 4 years ago | (#29330117)

Oh yeah, and which other scheduler's, if any, did this guy write?

SD scheduler [kerneltrap.org]

Re:Glory! (4, Insightful)

blind biker (1066130) | more than 4 years ago | (#29330205)

I wonder what BeOS had, that was so good. I mean, was it a scheduler thing? Or was it the pervasive multithreadedness that the OS almost forced upon the developers? Whatever it is, it worked like black magic: BeOS would always listen to the user input, no matter what the heck it was doing in the background, no matter what insane load was on the CPU - your mouseclicks were always reacted upon immediately, your drags were always reacted upon immediately, your typing, resizing, brushstrokes, midi-signals, whatever, always, under any circumstance, were immediately and smoothly followed by the correct response.

I was hoping Windows 2000 would achieve that, then I was hoping Windows XP would achieve that, then I was hoping some of the newer 2.6 kernels in Linux coupled with innovations in X would achieve that - but I was always deeply, utterly disappointed. Then I kinda hoped Vista would get somewhat close to what BeOS did. Oh yeah, now that was a hope decisively smashed.

Re:Glory! (1)

kojot350 (1330899) | more than 4 years ago | (#29330225)

According to the latest Ars Technica article about Snow Leopard, BeOS had used threads for everything and it didn't worked out quite well in the end unfortunately...

Re:Glory! (1)

blind biker (1066130) | more than 4 years ago | (#29330275)

According to the latest Ars Technica article about Snow Leopard, BeOS had used threads for everything and it didn't worked out quite well in the end unfortunately...

How so? Technically, BeOS as a user-friendly and responsive desktop environment, is still unbeaten. It tanked in marketshare, but that had nothing to do with using threads with everything.

Re:Glory! (2, Informative)

kojot350 (1330899) | more than 4 years ago | (#29330367)

"...While all that pervasive multithreading made for impressive technology demos and a great user experience, it could be extremely demanding on the programmer. BeOS was all about threads, going so far as to maintain a separate thread for each window. Whether you liked it or not, your BeOS program was going to be multithreaded."

"GCD embodies a philosophy that is at the opposite end of the spectrum from BeOS's "pervasive multithreading" design. Rather than achieving responsiveness by getting every possible component of an application running concurrently on its own thread (and paying a heavy price in terms of complex data sharing and locking concerns), GCD encourages a much more limited, hierarchical approach: a main application thread where all the user events are processed and the interface is updated, and worker threads doing specific jobs as needed."
Very good in-depth article btw. http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/1 [arstechnica.com]

Re:Glory! (0)

Anonymous Coward | more than 4 years ago | (#29330691)

a main application thread where all the user events are processed and the interface is updated, and worker threads doing specific jobs as needed

You mean like a BLooper processing messages from the app_server and passing them on to the appropriate thread(s) for the BWindow's & BView's? Yeah GCD is totally different...

Re:Glory! (1)

amn108 (1231606) | more than 4 years ago | (#29330309)

It is certainly a good thing - instant response (as far as the user is concerned, since "instant" is relative here). I have never used BeOS, and have to wonder - how was its "race-to-complete" task performance? If everything in the system was so catered to response timings but (concurrent) task performance suffered (in a pre-emptive multitasking OS, every task shares time with others, at least the CPU scheduler), then the user is not happy either. He/she wants instant response AND switft audio/video encoding/decoding (applications that are CPU bound).

Re:Glory! (0)

Anonymous Coward | more than 4 years ago | (#29330491)

This isn't run priorities causes this odd temporary lock-up, there's something weird going on with IO that freezes even simple things like entering keystrokes into terminals. It started somewhere in the 2.4 tree and it's very frustrating. I get it on OS X on the mac pro too, so I'm guessing it's triggered by something around how kernels handle SATA2.

Re:Glory! (1)

fsiefken (912606) | more than 4 years ago | (#29330595)

May I be the second to say "AMEN!". Linux is always said to be the fastest most responsive desktop os on older hardare. Still xp can beat x/gnome/linux 2.6 on a low end machine, perhaps this scheduler will change it.

*sniff* (4, Funny)

s4m7 (519684) | more than 4 years ago | (#29330075)

I smell another LKML flamewar coming....

Re:*sniff* (3, Funny)

tpgp (48001) | more than 4 years ago | (#29330271)

I smell another LKML flamewar coming....

A flamewar on the LKML? Pfffffffffffft. Impossible. Never happened, never will happen.

Uh... I don't see it included soon... (0)

imbaczek (690596) | more than 4 years ago | (#29330095)

What is it?

BFS is the Brain Fuck Scheduler.

yeah...

Linux gets Yet Another Scheduler (-1, Flamebait)

Zenin (266666) | more than 4 years ago | (#29330101)

This is news? Linux has been playing musical schedulers for years now. I've yet to be impressed by any of them, for any use, with any hardware.

Re:Linux gets Yet Another Scheduler (2, Interesting)

tpgp (48001) | more than 4 years ago | (#29330255)

I've yet to be impressed by any of them, for any use, with any hardware.

I've yet to be impressed by your comment, which contains no reason for your opinion.

Care to give us some examples of your uses & hardware?

Re:Linux gets Yet Another Scheduler (1)

Kjella (173770) | more than 4 years ago | (#29330629)

I've yet to be impressed by your comment, which contains no reason for your opinion. Care to give us some examples of your uses & hardware?

From looking at his posting history, I would say it's because Linux is GPL. He seems to have an axe or three to grind...

Re:Linux gets Yet Another Scheduler (0)

Anonymous Coward | more than 4 years ago | (#29330265)

Linux has been playing musical schedulers for years now.

"playing musical schedulers", WTF does that even mean? Maybe give examples of those and problems you achieved? Insightful my ass, but yeah /. sucks

Re:Linux gets Yet Another Scheduler (2, Funny)

deniable (76198) | more than 4 years ago | (#29330361)

Musical Schedulers? Let me guess, when the music starts to skip, a random process gets killed.

I tripped over this (0)

Anonymous Coward | more than 4 years ago | (#29330103)

I tripped over his site about 4 days ago, so this is old news to me (well 4 days old anyway). I didn't try adding his code to the kernel and doing a compile (I'm running Linux Freedom 2.6.31-rc8-git2 #1 SMP Fri Sep 4 19:22:35 MDT 2009 x86_64 GNU/Linux built with gcc version 4.4.1 (4.4.1) on Ubuntu 9.04) on a corei7-920. I might give it a try though. I also found out what BFS stood for. I might give it a try anyway.

Linux on the Desktop/Linux on the Server (2, Insightful)

erroneus (253617) | more than 4 years ago | (#29330105)

Clearly, Desktop Linux and Server Linux have some things in common, but they also have different needs. I'm not intimately familiar with any kernel programming but I do have some basic understanding of how it all works and even I find it relatively easy to understand that the needs of a good and snappy desktop and those of reliable server are going to have some differences.

I think it is beyond time that some sort of kernel operating mode optimizations are enabled like this scheduler thing for desktop even if the defaults are for server.

Re:Linux on the Desktop/Linux on the Server (1)

Hurricane78 (562437) | more than 4 years ago | (#29330567)

I'm really wondering where that either/or comes from... I mean they are like children "I want this!" "No, I want THAT!".

Put in a configure option like grown-ups, and like any other real developer, and be done with it!

Power really corrupts. And actually, I have this configure option in my kernel, because of some nice guy -- that is none of those whiners -- is doing a high performance patchset. I did not even know that others have no choice.

Re:Linux on the Desktop/Linux on the Server (1)

Kjella (173770) | more than 4 years ago | (#29330669)

Put in a configure option like grown-ups, and like any other real developer, and be done with it!

Even in a kernel there are many things that aren't performance sensitive, but the scheduler is not one of them. From what I understood from the kernel discussion last time, this would probably have to be #ifdefs galore. It's also not just the algorithm itself, everything that collects data for the scheduler to use also costs cycles. After all this runs 1000 times a second, it has to be as lightweight as possible.

Cool, but what does that spec mean? (0, Funny)

Anonymous Coward | more than 4 years ago | (#29330115)

While I think it's great for Linux to have more choice in schedulers, I don't understand Con's spec at all:

BFS 'was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware

Hang on there, something's not right with that logic:

1) If you're forward looking, how can you not scale beyond 16 cores? We're already at 8 cores on home boxes.

2) And if you're forward looking only, then how come that you're looking backwards at lower spec machines?

Whoever wrote that piece just produced a sound bite that's logically meaningless.

Re:Cool, but what does that spec mean? (1)

Effugas (2378) | more than 4 years ago | (#29330139)

Uh, a few machines have eight cores. Core2Duo is doing OK, but really, the heat problem is not actually going away in any way shape or form.

Re:Cool, but what does that spec mean? (5, Informative)

Trepidity (597) | more than 4 years ago | (#29330165)

He means something different by it--- that the scheduler should only look forward, not look back to per-process history in making its scheduling decisions. A common hack/heuristic to improve interactive performance is to boost the priority of processes that sleep a lot, since CPU-bound jobs sleep rarely, while interactive processes sleep a lot. Kolivas think that's a hack that obscures the real problems with interactive performance, and leads to unpredictable performance since it doesn't fix the underlying issues. So wants to design schedulers with good interactive performance that make decisions based purely on the current set of running processes and priorities, and the upcoming timeslices.

Re:Cool, but what does that spec mean? (1)

amn108 (1231606) | more than 4 years ago | (#29330195)

I think he means "forward looking" in the sense that scheduler does not collect samples from anything that already happened, it only makes decisions on what happens immediately after.

Re:Cool, but what does that spec mean? (0)

setagllib (753300) | more than 4 years ago | (#29330207)

It's a scheduler term, not a hardware requirement strategy. Leave the tech to the people who know (certainly not me, but Con is epic).

O SNAP! (0, Offtopic)

uwnav (1009705) | more than 4 years ago | (#29330127)

oh no he didn't! HE CAME BACK!?!

He's like the Brett Favre of linux kernel schedulers!

hmm.. wrong place to use football reference?
who am I kidding.. I don't watch football

forward looking (5, Informative)

Trepidity (597) | more than 4 years ago | (#29330141)

Took me a while to figure out what "forward looking" means in this context, since "forward-looking scheduler" doesn't seem to be common terminology, and I assumed he wasn't talking about his grand forward-looking vision for schedulerdom.

Based on some previous arguments he's had, it sounds like he opposes the common heuristic of upping interactive process priority by keeping track of how long processes sleep--- processes that sleep a lot are probably I/O bound, and should get a priority boost so they can run on the (less frequent than for CPU-bound processes) occasions when they're ready. Kolivas wants schedulers to be forward-looking in the sense that they decide how to schedule without looking at process run history, by looking purely at who's ready to run, available timeslices, priorities, etc.

Re:forward looking (0)

drinkypoo (153816) | more than 4 years ago | (#29330573)

IANAKernel Developer but I predict right now that as in all other things the correct approach will be to look at past, present, and future. That is the only hope of fulfilling Linus' dream of having a single scheduler which serves all users. What process is doing what right now, what did they do last, what are they likely to do next. Today becomes tomorrow, starting from yesterday.

Who cares? (-1, Flamebait)

internet-redstar (552612) | more than 4 years ago | (#29330149)

Who cares about his scheduler focus, while performance bottlenecks and especially his 'examples' are mostly I/O related. If a make -j 4 makes your quadcore machine choke, it's indeed a BRAINFUCKED coder who made it... CPU cycles should be plentifull available in between the I/O operations. Still wonder why he's able to get that much media attention... ... luckily nobody on LKML cares neither...

Re:Who cares? (1)

amn108 (1231606) | more than 4 years ago | (#29330327)

I am not sure what you are trying to paint here. If you have four cores, and do a compilation through 4 jobs, the compilation will race to complete and optimally should load all cores (especially since you explicitly told it to do it 4-way). Also, compilation is not all that I/O bound, it is more CPU bound. Anyways, I think I missed the meaning of your post entirely. Explain please... :-)

Re:Who cares? (1)

internet-redstar (552612) | more than 4 years ago | (#29330399)

On very slow CPU's compiling something might seem to be CPU bound, but with modern hardware it isn't anymore. Take compiling the kernel as an example. In his FAQ, he uses make -j as an example for CPU bound processes. In modern hardware it's more of an I/O bound process than CPU bound. This is also why you will still see a lot of CPU idle time on make -j 2 on a dual core with a 'normal' scheduler. And that's also what it should be. If you create a scheduler who has in the same situation less idle time, it only means that you have created a less efficient one... and one shouldn't celebrate a better scheduler! :) Test cpu intensive load with CPU bound processes, I/O bound with I/O bound processes. But if a scheduler designer thinks make is a CPU bound process, should we even take time to look at his code?

Re:Who cares? (1)

amn108 (1231606) | more than 4 years ago | (#29330427)

Ok, I get it now. Will take time to process :-)

P.S. Compilers are getting more and more intelligent these days, and intelligence comes at the price of CPU cycles, so it would be more observant to say that indeed even with modern hardware, compilers developing in parallel, they still are keeping up to remain CPU-bound? But you are of course right about C compilers (which is what kernel stuff is built with), these develop much slower (lack of necessity, really) and thus the hardware has outran their needs by now, making them I/O bound indeed.

Re:Who cares? (0)

Anonymous Coward | more than 4 years ago | (#29330713)

Or instead of trolling you could acknowledge that his benchmarks show not only higher CPU utilization, but also faster completion times.

Re:Who cares? (0)

Anonymous Coward | more than 4 years ago | (#29330377)

You didn't even bother reading the article did you...

make -j4 doesn't make your quadcore max, that's the issue, look in most make manuals and you'll find it recomends cpu's+1 atleast to max out cpu usage. BFS will run maxed with -j4.

Re:Who cares? (1)

internet-redstar (552612) | more than 4 years ago | (#29330429)

I did bother to read the article.

And the fact that BFS isn't even able to properly schedule n+1 lightly-cpu-bound processes certainly doesn't talk in it's favor.

But it's true; I haven't tested the code yet, and miracles could exist, but his analysis isn't confidence inspiring - to say the least.

You're welcome! (1)

dvh.tosomja (1235032) | more than 4 years ago | (#29330159)

I for one, welcome our new Bloody Fucking Scheduler overlords!

Once the article gets slashdotted, text here (0)

Anonymous Coward | more than 4 years ago | (#29330169)

The content of http://ck.kolivas.org/patches/bfs/bfs-faq.txt [kolivas.org] below, geeks wanna know

FAQS about BFS. v0.209

Why did I write it?

After years of using my old kernel and numerous hardware upgrades, I finally
had hardware that needed a newer kernel for drivers and to try out the newer
filesystems. Booting the mainline kernel was relatively reassuring in that
the scheduler behaviour was much better than what was in earlier kernels.
However, it didn't take long before I started being disappointed in that too.
Random stalls in mouse movements, keypresses, strange cpu distribution in
various workloads and unpredictable behaviour all around were exactly what I
was hoping had gone away. So I did what I vowed never to do, looked at the
code. After seeing it had grown into a monster of epic proportions I sat down
and thought about what was wrong. One of the key features of fairness and
interactivity that I always argued for were very simple semantics for how
cpu should be distributed, with guaranteed low latencies so that interactivity
was assured by design instead of bolted on. CFS in essence does that, but it
does something else too. It varies timeslice length to try and preserve some
deadline list and it determines cpu distribution based on a run/sleep
relationship. It also is designed to scale to monster proportion hardware
that the common man will never see. The whole sleep calculation thing is
exactly what I found was responsible for making varied behaviour under
different loads and relative starvation and unfairness. It's not a profound
effect in CFS and that's admirable. It just doesn't behave the way I feel
the scheduler should being forward looking only (not calculating sleep) and
it doesn't really make the most of a relatively lightly loaded machine without
many many cpus. So I threw it all out and wrote exactly the opposite.

What is it?

BFS is the Brain Fuck Scheduler. It was designed to be forward looking only,
make the most of lower spec machines, and not scale to massive hardware. ie
it is a desktop orientated scheduler, with extremely low latencies for
excellent interactivity by design rather than "calculated", with rigid
fairness, nice priority distribution and extreme scalability within normal
load levels.

Extreme scalability within normal load levels? Isn't that a contradiction?

For years we've been doing our workloads on linux to have more work than we
had CPUs because we thought that the "jobservers" were limited in their
ability to utilise the CPUs effectively (so we did make -j6 or more on a
quad core machine for example). This scheduler proves that the jobservers
weren't at fault at all, because make -j4 on a quad core machine with BFS
is faster than *any* choice of job numbers on CFS. See reverse scalability
graph courtesy of Serge Belyshev showing various job numbers on a kernel build
on a quad core machine. The problem has always been that the mainline
scheduler can't keep the CPUs busy enough; ie it doesn't make the most of
your hardware in the most common situations on a desktop! Note that the
reverse scalability graph is old; the scalability has improved since then.

Why "Brain Fuck"?

Because it throws out everything about what we know is good about how to
design a modern scheduler in scalability.
Because it's so ridiculously simple.
Because it performs so ridiculously well on what it's good at despite being
that simple.
Because it's designed in such a way that mainline would never be interested
in adopting it, which is how I like it.
Because it will make people sit up and take notice of where the problems are
in the current design.
Because it throws out the philosophy that one scheduler fits all and shows
that you can do a -lot- better with a scheduler designed for a particular
purpose. I don't want to use a steamroller to crack nuts.
Because it actually means that more CPUs means better latencies.
Because I must be fucked in the head to be working on this again.
I'll think of some more becauses later.

How scalable is it?

I don't own the sort of hardware that is likely to suffer from using it, so
I can't find the upper limit. Based on first principles about the overhead
of locking, and the way lookups occur, I'd guess that a machine with more
than 16 CPUS would start to have less performance. BIG NUMA machines will
probably suck a lot with this because it pays no deference to locality of
the NUMA nodes when deciding what cpu to use. It just keeps them all busy.
The so-called "light NUMA" that constitutes commodity hardware these days
seems to really like BFS.
The O(n) lookup of BFS will cause people some concern because of the
notation. However, if the actual overhead is very small, then even with
large numbers of n, it can be lower overhead than an O(1) design. Testing
this scheduler vs CFS with the test app "forks" which forks 1000 tasks that
do simple work, shows no difference in time to completion compared to CFS.
That's a load of 1000 on a quad core machine. But note that BFS gets much
faster when the loads are lower and approximate the number of CPUs, which
is much more what you would experience on a desktop.

What about interbench numbers?

Interbench does too many jobs by default on the burn/compile tests. I've put
up interbench results from a quad core where the jobs (4) is equal to the
number of CPUs so the test is more meaningful, and added comments.

What features does BFS have and not have?

On top of the current scheduler design, it has a SCHED_IDLEPRIO which actually
does only schedule tasks when idle, and SCHED_ISO for unprivileged realtime
performance. BFS does NOT implement CGROUPS. A desktop user should not need
know about CGROUPS, nor should they need to use them. BFS also does not have
the feature of "lots of tunables I don't understand".

How do you recommend I use this?

It's designed so that you just patch it in and use it. You shouldn't need to
do anything at all. But since people still want to know every last thing...

THESE ARE OPTIONAL FOR LOWEST LATENCY. YOU DO NOT NEED THESE!
Configure your kernel with 1000Hz, preempt ON and disable dynamic ticks.

You shouldn't need to tune BFS virtually ever. The only tunable for the
scheduler itself is the rr_interval value (see documentation). Try 3ms if
latency is everything to you. When compiling software, do not use more jobs
than you have CPUs! So make -j2 on dual core, -j4 on quad core and so on.
Nice levels are strictly obeyed so if you nice your compiles they'll be
virtually unnoticeable. (nice -n 19 make -j2). Run your distributed computing
clients SCHED_IDLEPRIO (eg folding at home, mprime etc):
schedtool -D -e mprime
Run your audio and video apps SCHED_ISO:
schedtool -I -e amarok

NUMA aware?

It is NOT NUMA aware in the sense that it does any fancy shit on NUMA, but
it will work on NUMA hardware just fine. Only the really big NUMA hardware
is likely to suffer in performance, and this is theoretically only, since
no one has that sort of hardware to prove it to me, but it seems almost
certain.

Multicore processors?

This is where BFS shines.

I found a bug!

Great! Help me debug it. A scheduler is subtle and quick to anger. If you can
code then delve away and see what you can find! I'll take help from anyone.
It's a major ordeal trying to get this thing working on all sorts of hardware.
You can't code? Give me whatever details you've got and I'll see what I can
do. As per usual this stuff comes with no guarantee, and I do not have
infinite time to spend on it. I do NOT get paid to do this and do it just for
the fun of it. I'll do whatever I can to help you but I cannot support this
like a paid project. I'd *love* to see people hacking on the code themselves.

Are you looking at getting this into mainline?

LOL.

No really, are you?

LOL.

Really really, are you?

No. They would be crazy to use this scheduler anyway since it won't scale to
their 4096 cpu machines. The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter. Besides, apparently I'm a bad
maintainer, which makes sense since for some reason I seem to want to have
a career, a life, raise a family with kids and have hobbies, all of which
have nothing to do with linux.

Can it be made to scale to 4096 CPUs?

Sure I guess you could run one runqueue per CPU package instead of a global
one and so on, but I have no intention whatsoever at doing that because it
will compromise the performance where *I* care.

Is this stable?

Probably not. I use it on half a dozen machines but the code only booted for
the first time successfully on the 25th August 2009 so you work out how new
it is.

Currently known problems?

1. Intermittent boot failures on some hardware.
2. Stuck tasks on the same hardware as 1. after extended periods, suggesting
      a common problem.
3. Stuck tasks after extensive use of trace functions (ptrace etc.). Note that
      some distributions' package managers use trace functions.
4. Failure to suspend on some hardware.
5. More likely to show up bugs in *other* code due to being much more
      aggressive at using multiple CPUs so race conditions will show up more
      frequently.
6. Load calculation is broken by a suspend/resume cycle.

ATI drivers seem particularly unhappy with smp and preempt and bfs, suggesting
they're racy and very prone to #5.

I'm working on all of the above now and have no time frame whatsoever for when
they might be fixed since I don't know what's causing them (except for 5).

GIT repository?

Sorry, it's not the right tool for me so it's not worth me investing the time
in setting one up.

What is the relationship of BFS to SD?

BFS implements the same forward-looking rigidly fair timeslicer philosophy
that SD used, but is otherwise a completely different scheduler. It
is an attempt to fuse all the ideas I have about scheduling so far, without
worrying about trying to make it infinitely scalable.

Thanks to the guys in irc.oftc.net #ck for inspiration to work on this and
early testing! Many of them sat idle in that channel for years while nothing
happened. The xkcd comic supported_features also helped motivate this
work. Yes I know you probably still can't watch full screen videos on youtube,
but that's not entirely the scheduler's fault.

Work in progress.

Last updated: Sun Sep 6 18:26:33 2009
Con Kolivas

Welcome back Kolivas (2, Funny)

Black Sabbath (118110) | more than 4 years ago | (#29330187)

Haven't run Linux as my personal OS since 2003 but I had a lot of time (pun intended) for CK's schedulers. Now a whole new generation of youngsters can finally learn what a _REAL_ LKML flamewar looks like ;-)

What about FreeBSD? (0)

Anonymous Coward | more than 4 years ago | (#29330217)

I always get a much smoother and more responsive X experience on FreeBSD. An extreme example: years ago I could run FreeBSD in vmware (headless, connect with a native X term ie WinX32) just like a native machine while Redhat is slow like a snail. Is this because FreeBSD is genuinely fast?

Re:What about FreeBSD? (1)

MichaelSmith (789609) | more than 4 years ago | (#29330325)

Don't know about freebsd but I have had many linux systems lock up with a runaway process. Never happened to me on netbsd.

Re:What about FreeBSD? (2, Informative)

markdavis (642305) | more than 4 years ago | (#29330547)

Almost all runaway processes are due to bugs in the end applications, not some situation created by the kernel.

Re:What about FreeBSD? (0)

Anonymous Coward | more than 4 years ago | (#29330645)

NOTHING a userland application does should cause system lockup. Such situation is always kernel bug.

i.e. vs e.g. (0, Offtopic)

Troed (102527) | more than 4 years ago | (#29330227)

"i.e." should be used after a statement to explain it another way

Remove the [sic]

http://askville.amazon.com/define-correct-usage/AnswerViewer.do?requestId=5300847 [amazon.com]

Re:i.e. vs e.g. (0)

Anonymous Coward | more than 4 years ago | (#29330283)

The submitter most likely has English or American as his/her first language and thus can't speak, write, or read it properly, i.e. forgiveness is in order :D

Re:i.e. vs e.g. (0)

Anonymous Coward | more than 4 years ago | (#29330357)

i.e., cannot be used where the word "therefore" is needed. i.e. is probably best used where you would otherwise put the phrase "that is to say..." or "in other words..."

Re:i.e. vs e.g. (0)

Anonymous Coward | more than 4 years ago | (#29330401)

Its use in the summary quote is correct, except for capitalization. (The original text is "ie it is..." though. That makes the "[sic]" extra annoying.)

Your explanation does not contradict the use of "i.e." in that sentence. It is not "therefore" a desktop scheduler. It does not scale to massive hardware. In other words, it is a desktop scheduler.

Re:i.e. vs e.g. (1)

Hal_Porter (817932) | more than 4 years ago | (#29330421)

I.e = id est = that is.
E.g. = exempli gratia = for example.
[sic] = this = when quoting an error.

And yes, i.e. was used correctly so no [sic] should be needed. Then again the editor probably just put it in to catch pedants.

4096 cpu machines (4, Interesting)

boldie (1016145) | more than 4 years ago | (#29330241)

Still some grudge towards Torvalds and Molnar? From the FAQ:
Are you looking at getting this into mainline?
LOL.

No really, are you?
LOL.

Really really, are you?

No. They would be crazy to use this scheduler anyway since it won't scale to their 4096 cpu machines. The only way is to rewrite it to work that way, or to have more than one scheduler in the kernel. I don't want to do the former, and mainline doesn't want to do the latter. Besides, apparently I'm a bad maintainer, which makes sense since for some reason I seem to want to have a career, a life, raise a family with kids and have hobbies, all of which have nothing to do with linux.


Reminds me of this XKCD [xkcd.com] .

I don't have 4096 CPUs, good job Con Kolivas!

Re:4096 cpu machines (0)

Anonymous Coward | more than 4 years ago | (#29330253)

Reminds you of it? Look at the bottom. He actually credits that particular comic.

I like the idea. It may be a fun experiment, and even if it isn't mainline, this could be something that, in time, downstream distros might experiment with (I'm looking at you, Ubuntu Desktop).

Re:4096 cpu machines (1)

boldie (1016145) | more than 4 years ago | (#29330273)

Haha, there it is! Did'nt read the whole linked article. I'm hoping for it to appear in downstream too.

Re:4096 cpu machines (2, Interesting)

amn108 (1231606) | more than 4 years ago | (#29330345)

Well who knows, maybe instead of the elusive year of Linux on desktop, we should be expecting and applauding years of downstream personal automated-installing GNU/Linux distributions like LFS or diy-linux, which will let users to choose schedulers and what not. Not exactly something I expect to happen soon, but my feeling is GNU/Linux is being institutionalized. It is like if the trust is just not there to anything but the mainline. People assume that the majority is right here - that the maintainers of mainline kernel know best - and every other hacker in minority like Con, is just experimenting. What if we can distribute this trust better - use "non-standard" schedulers etc - then the benchmarking will reach the users and the truth will be distilled eventually. If Cons new scheduler is as good as he tries to paint it, build kernel and use it in thousands. Currently, all eyes are on mainline, which is what prevents choice, even though the choice is "potentially" there.

Re:4096 cpu machines (1)

ultranova (717540) | more than 4 years ago | (#29330583)

What if we can distribute this trust better - use "non-standard" schedulers etc - then the benchmarking will reach the users and the truth will be distilled eventually. If Cons new scheduler is as good as he tries to paint it, build kernel and use it in thousands. Currently, all eyes are on mainline, which is what prevents choice, even though the choice is "potentially" there.

Unfortunately, the internal interfaces of Linux kernel are constantly being modified, so maintaining an "alternative" kernel has a huge overhead. You either miss out on updates to the mainline kernel, or keep on changing your patches to keep them compatible with it.

The more cynical part of me wonders if Linus is doing that on purpose, to reduce competition? Make it a pain to maintain a forked kernel, and people will improve mainline. Of course that also means that desktop users are stuck with data center optimizations, but it also keeps them from having good alternatives, so Linux usage will keep on growing.

Re:4096 cpu machines (1)

HyperQuantum (1032422) | more than 4 years ago | (#29330523)

Reminds me of this XKCD [xkcd.com] .

From the FAQ:

The xkcd comic supported_features also helped motivate this work.

He ain't kidding. (4, Insightful)

Ant P. (974313) | more than 4 years ago | (#29330285)

CFS can't even cope with a CPU-bound application [foldingforum.org] .

Who here runs Linux on anything with more than 16 cores? Why should everyone else get the shitty end of the stick just because of maybe a dozen institutes with deep pockets?

Re:He ain't kidding. (2, Interesting)

dbIII (701233) | more than 4 years ago | (#29330411)

I don't know about you, but I run 8 CPU linux cluster nodes at 100% on all CPUs for weeks at a time and I'm only at the very bottom end of "high performance computing". For about two minutes in total a day the nodes are dumping things to disk (snapshots) and are I/O bound. The rest of the time they are pegged at 100% until the job finishes (which takes days to weeks - geophysical stuff). There are several applications that behave this way on these nodes, but there are some that sit waiting doing nothing because they are badly written. That means I think your above statement is a strongly misleading pile of steaming rubbish.

Re:He ain't kidding. (2, Insightful)

markdavis (642305) | more than 4 years ago | (#29330507)

>Who here runs Linux on anything with more than 16 cores?

Along the same lines... Who here runs their Linux *servers* with 16 or *less* cores? Probably 99.9%?

And "server" doesn't really mean anything. At work, we use Linux thin clients, so the Linux "server" is really dealing with 150 desktops, except not managing X/kb/mouse. So should it be treated like a "server" or a "desktop" for scheduling?

Re:He ain't kidding. (0)

Anonymous Coward | more than 4 years ago | (#29330517)

With dual-core netbooks on the horizon, and desktops with 4 hyper-threading cores available which appear as 8 cores to a scheduler, it's only another couple of years until the high-end PC market goes past 16 cores. If software evolves enough to make use of this extra processing capability we'll carry on into stupid numbers.

Re:He ain't kidding. (1)

delirium of disorder (701392) | more than 4 years ago | (#29330553)

Who here runs Linux on anything with more than 16 cores?

My personal server. [sun.com] A debian based distro of Gnu/Linux is much easier for me to admin than Solaris. Massively multicore is the future. I wouldn't buy any new computer with less than 16 cores/hardware threads. Well, except for laptops and embedded systems.

Re:He ain't kidding. (1)

A beautiful mind (821714) | more than 4 years ago | (#29330627)

CFS can't even cope with a CPU-bound application.

Note that the thread you linked to compared schedulers based on per process CPU "usage" levels (90-95% vs 100%). Those numbers are not accurate representations of anything close for evaluating scheduling algorithms. There are many reasons for that, but let me just say that the number given there depends upon sampling and can be wildly inaccurate.

If they really wanted to test CPU gains from scheduling efficiency, they should have tested the difference in time between a specific work unit when using different schedulers, eliminating the need to rely on an indirect and inaccurate sampling method and measuring what's important: work done in a given amount of time.

Re:He ain't kidding. (1)

bollucks (450288) | more than 4 years ago | (#29330743)

Read the posts. He may have been saying that it "can't cope" and used the % of cpu argument, but he also found that it shortened the time taken to complete his workload. quote: Frame time reduced by 2 mins on my O/C'd 3.8Ghz i7 920 (-bigadv -smp 8) with the bfs scheduler.
I don't know how long the workload normally takes so it doesn't really say what percentage improvement that is, but it is exactly what you asked for. It's also interesting to note that this is on an 8 (logical) CPU machine.

16... okay for the desktop for 12 months (4, Interesting)

MosesJones (55544) | more than 4 years ago | (#29330347)

16 sounds like a ridiculously high number for a desktop but is it?

Already we have 4 core processes which have "soft" additional threads (Intel's HT for instance) and some people already have dual CPU desktop machines meaning they are already at the 16 CPU limit.

Roll on 12-18 months and we'll be seeing 8 core CPUs with 8 soft-cores as coming in on top end desktops. Roll forwards 3 years and you'll be seeing 32 core CPUs with 32 soft-cores which is where the scheduler breaks down.

So the problem here is that this is a brilliant optimisation for today and for pieces like the netbook market but won't be good for the desktop market long term.

With Linux looking to be strong in the netbook market however it does say that having a more efficient scheduler for that market would be a better idea than just optimising everything for the server side.

Re:16... okay for the desktop for 12 months (1)

silanea (1241518) | more than 4 years ago | (#29330467)

[...] So the problem here is that this is a brilliant optimisation for today and for pieces like the netbook market but won't be good for the desktop market long term. [...]

How is this a problem? The scheduler supposedly (I did not test it) works well for the current situation, so it should be looked into and used if it holds up to its promises. And when the technical progress renders it outdated, it should be discarded and replaced with something better.

I would rather have a better scheduler right now and switch again in three years than put up with one which works suboptimal now and may or may not run better on future hardware.

GIT repository? (1)

MichaelSmith (789609) | more than 4 years ago | (#29330403)

The FAQ:

Sorry, it's not the right tool for me so it's not worth me investing the time
in setting one up.

C'mon Con. DSCM is a great way to distribute forks of software. If you don't like git (I don't) there is a mercurial mirror [kernel.org] of the linux kernel available and hosting a repository is dead easy. There are plenty of free options anyway. Or ask me.

Well? (0)

Anonymous Coward | more than 4 years ago | (#29330463)

Maybe if someone were to hook this up with OSS in Ubuntu... we could be looking at a distro that's finally suitable for music production?

Pluggable schedulers need to come back (1)

OrangeTide (124937) | more than 4 years ago | (#29330505)

I only care about 200-800MHz single core ARM performance. When I do have a dual-core ARM, I'm only running Linux on one core in that situation. Not only am I am evil bastard that doesn't cared about desktop performance, like those nasty server-oriented kernel maintainers, I also don't care about server performance!

That said I think I like his scheduler for embedded. I may have to try the patch out at work and see how many apps and drivers choke because it exposes their races.

I could do without his emotional baggage in his BFS faq though.

Erm... (1)

_Shad0w_ (127912) | more than 4 years ago | (#29330521)

Why have you put an editorial "sic" in there? "i.e." is perfectly valid in the context in which it was used, it's an abbreviation of the Latin, "id est", or "that is".

The quote, if read in a manner expanding the abbreviation, would read "...and not scale to massive hardware. That is, it is a desktop orientated scheduler..." I would probably have changed the full stop after "hardware" to a semicolon, but that's me.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...