# CFS to be merged in 2.6.23!

## jsf_x35a

Am I the only one excited?   :Very Happy: 

----------

## Genewb

 *jsf_x35a wrote:*   

> Am I the only one excited?  

 

Supposedly it's in git1, which I'm running at the moment.

Not sure how to measure the difference though  :Wink:  Every change I make seems snappier. More a matter of wishful thinking and confirmation bias than real performance improvements, methinks.

----------

## jsf_x35a

Well, I suppose on newer systems you wouldn't really notice the difference since they are snappy enough as it is. My old machine though is a 5 year old Williamette and switching to CFS made Warcraft 3 (wine) run significantly smoother and my in game audio stopped skipping. 

But you're right, on new desktop (5 months old) desktop it didn't make much of a difference. The only significant difference I saw was that CPU usage was lower but that didn't seem to affect the actual startup times of anything.

----------

## SiberianSniper

meh, I prefer SD

----------

## jsf_x35a

 *SiberianSniper wrote:*   

> meh, I prefer SD

 

Actually I started my fair scheduling experience with SD. The only reason I've switched to CFS is because Con announced that his last patch is going to be for 2.6.22. I wish he would continue I really wanted to see RSDL in stable action, but he has his reasons for stopping.

----------

## SiberianSniper

True, and I respect those reasons.  But 2.6.22 will be my last kernel for a while (until I have a really good reason to upgrade)

----------

## zeek

Shades of Reiser4 vs Ext4 all over again.  Developers working on enhancements get their code stonewalled while Linus' inner circle get their code merged so it can get wider visibility and testing.

Con developed and proved SD/RSDL in the open and this is not the way to repay all that hard work.  The kick in the teeth is Ingo Molnar who wrote the SD ripoff CFS was originally Con's biggest critic.

I never realized this until now but Linux is an Old Boys Club(tm).

----------

## mudrii

in 2.6.23 we will find  Swap Prefetch patch from Con 

Ref

http://kerneltrap.org/node/11748

----------

## kernelOfTruth

at least that found its way into mainline, otherwise all of con's work would have been for the dust bin   :Sad: 

in the meantime cfs seems to have gotten way better than sd (very subjective opinion)   :Shocked: 

give your dual or quad-core rig some work to do (compiling openoffice or such with MAKEOPTS=-j9 or more) then have a look at the cpu load-balancing (e.g. with gnome-system-monitor or kde's equivalent) , it's great   :Smile: 

----------

## Paapaa

I bet nobody will notice any significant improvements in normal desktop usage. Things get more interesting in heavy multitasking.

Nevertheless, always good to see Linux getting better and better all the time   :Very Happy: 

----------

## zeek

 *mudrii wrote:*   

> in 2.6.23 we will find  Swap Prefetch patch from Con 
> 
> Ref
> 
> http://kerneltrap.org/node/11748

 

Too little, too late.  Con already announced that he is throwing in the towel on kernel development.  :Sad: 

Great quote from that thread btw:

 *Quote:*   

> Save a Redhat employee some time reinventing the wheel and just merge it.  This wheel already has dope 21" rims, homes 

 

----------

## lagalopex

I tried the cfs-v19 patch for the 2.6.21.6 with the gentoo-sources 2.6.21-r4 on my amd64 system.

What I can say: The mouse is not smooth at all (like 2 fps...) and in the time I tested it (~2 hours) I could see how kdesktop was terminated (no message nowhere) and twice it hit amarok into the nowhere...

I think something is really wrong with it, I can only hope they'll fix it their way to 2.6.23...

----------

## Paapaa

 *lagalopex wrote:*   

> I think something is really wrong with it, I can only hope they'll fix it their way to 2.6.23...

 

You should definitely report your findings to Ingo via LKML. That is the best way to get it fixed - if CFS is the reason.

----------

## lagalopex

Well, the exact same kernel without the cfs-patch is running fine here  :Wink: 

But I dont know, what they already fixed... and I dont really want to fetch a git-kernel... the rc1 I'll try when its out...

----------

## Dominique_71

 *zeek wrote:*   

> Shades of Reiser4 vs Ext4 all over again.  Developers working on enhancements get their code stonewalled while Linus' inner circle get their code merged so it can get wider visibility and testing.
> 
> Con developed and proved SD/RSDL in the open and this is not the way to repay all that hard work.  The kick in the teeth is Ingo Molnar who wrote the SD ripoff CFS was originally Con's biggest critic.
> 
> I never realized this until now but Linux is an Old Boys Club(tm).

 

You are right. I am not a developer, but I can see when something is going wrong. And I don't like at all the actual policy of the kernel development. This problem with Con that provided a hard and outstanding work and was just mobbed by the big guys is a good example.

Another example is at some old and buggy features are marked as obsolete instead of fixing them, and replaced by other features they are at least as much buggy. See the ide-scsi that was working in most cases with a few minor and well know bugs. It is now replaced by the ide-cd that is more buggy. The main problem with this particular case is at the big guys don't even have a CD or a DVD drive to try it and at they don't care about it.

Another issue with the kernel is at it is a real nightmare for a guy like me to do an usable kernel bug because of the complete lack of understandable documentation. Again, I am not a developer but I will help if I can. It is plenty of kernel doc, but they are written by developers for developers, not for end-users like me. I was trying to do such a bug report. It take me days, around 2 weeks to do the best I was able to do.  I get good feelings and answers from the guys on linux-acpi@vger.kernel.org. They tell me to do a bug report on the mainline kernel bugzilla with all the matter we was discussing. I done this bug report and send 2 messages on the kernel email list but never get an answer.

And I am not alone in this case. The amount of the bugs in the 2.6 kernel tree is just increasing with time. That and the fact at, with the actual policy of the manufacturers they incorporate drm at the hardware level and they don't release the documentation otherwise as against big money, it is becoming harder to develop the kernel modules, All that make me to wonder if the linux kernel have a future on the long run, or if it is better to look forward another kernel that will be able to run the gnu softwares.

----------

## kernelOfTruth

 *Quote:*   

> /	
> 
> From	Con Kolivas <>
> 
> Subject	Re: -mm merge plans for 2.6.23
> ...

 

so swap prefetch wasn't merged into .23 ?

man those guys SUCK   :Evil or Very Mad: 

the performance gain was OBVIOUS (I experience it EVERY DAY) if they don't merge it the least they could do is fixing this issue / investigating that this is problem is gone when final .23 gets out

 *Quote:*   

> I never realized this until now but Linux is an Old Boys Club(tm).

 

it seems so   :Crying or Very sad: 

----------

## Sachankara

 *zeek wrote:*   

> I never realized this until now but Linux is an Old Boys Club(tm).

 It has always been like that. There's lots of useful code that have been scrapped just because the main kernel developers didn't have a use for the stuff. They were and are unable to see past their own noses so to speak; if they don't have any use for the code themselves, they'll remove it or refuse to merge it with the mainline kernel.

----------

## charlieg

I wrote an article on this:

http://freegamer.blogspot.com/2007/07/dedicated-to-con-kolivas.html

A bit off-topic for my site (open source games) but, hell, it's my site.  :Cool: 

----------

## Paapaa

 *charlieg wrote:*   

> I wrote an article on this:
> 
> http://freegamer.blogspot.com/2007/07/dedicated-to-con-kolivas.html

 

Few things:

1. Linus chose CFS mainly because he trusts Ingo, he knows Ingo can and will maintain his patches with commitment, it is easy to communicate with Ingo, Ingo tries to fix all bugs reported to him etc. Linus couldn't say the same about Con. Those are all very valid reasons.

2. CFS is still very, very young and despite that it is now even better than SD in many respects. Even the horrible 3D bugs are beginning to be a thing of past. CFS is also said to scale better than SD. This suits Linux very well.

3. The competition was a good thing for all of us. Con did a first version and Ingo made a better one with some refinements - this happens all the time. We all win. And Ingo has given credit to Con for his work.

I can understand that this is a blow to all Con fans. But IMO only the end result matters: we get a better scheduler (with many additional features like group scheduling) with a trustworthy maintainer.

I think Linus did the only sensible solution at this point.

----------

## kernelOfTruth

 *Quote:*   

> CFS is also said to scale better than SD. 

 

it's not only said to scale better, it actually DOES scale better   :Wink: 

have a look at the cpu load-graph & you'll see what I mean (on SMP-systems)

there are still glitches on X with mouse & sound hickups (even on v19.1)   :Sad: 

but I think that will be all fixed in .23   :Cool: 

----------

## Dralnu

 *Paapaa wrote:*   

>  *charlieg wrote:*   I wrote an article on this:
> 
> http://freegamer.blogspot.com/2007/07/dedicated-to-con-kolivas.html 
> 
> Few things:
> ...

 

Didn't Ingo start out taking all the credit for himself? I think the big problem with the whole SD vs. CFS debate was that Ingo seemed to rewrite Con's work, took credit for it to begin with, and after some pressure gave some credit to Con. At what point did it ever occure to him to, you know, try and work WITH Con instead of basically (what could be taken as, in any case) taking advantage of Con's medical conditions, bashing out a new schedueler, and taking the glory for himself.

Con did alot of good work, got stonewalled, end of story. It doesn't matter so much which is better - Ingo stole Con's work, and used his position to get his merged instead. You have no way of knowing whether or not the SD would have outworked CFS in the long-run, nor does anyone else now. The fact that it doesn't even seem that Linus or Ingo even really gave Con's work any real second look is kind of annoying (and arrogant), and has such uncovered (at least moreso) the kind of path the kernel is taking.

Its great the old, shitty sked got canned, but the actions taken in and around it has brought up alot of questions.

----------

## Paapaa

 *Dralnu wrote:*   

> Didn't Ingo start out taking all the credit for himself? I think the big problem with the whole SD vs. CFS debate was that Ingo seemed to rewrite Con's work, took credit for it to begin with, and after some pressure gave some credit to Con. 

 

You are totally wrong here. Have you read the first announcement of CFS? I'll quote it for you:

 *Ingo Molnar wrote:*   

> i'd like to give credit to Con Kolivas for the general approach here:
> 
> he has proven via RSDL/SD that 'fair scheduling' is possible and that
> 
> it results in better desktop scheduling. Kudos Con!

 

http://kerneltrap.org/node/8059

 *Dralnu wrote:*   

> It doesn't matter so much which is better - Ingo stole Con's work, and used his position to get his merged instead. 

 

"Stole Con's work". Have you even compared the patches? Ingo didn't steal anything. He saw one implementation of fair scheduling (which Con did not invent), and he got motivated after seeing some well working patches from Mike Galbraith. Taking influence on others' work is a good thing, not a bad one.

 *Dralnu wrote:*   

> You have no way of knowing whether or not the SD would have outworked CFS in the long-run, nor does anyone else now. 

 

True, but I know that CFS is starting to be better than SD despite its very young age. CFS was born on the 13th April 2007, Staricase scheduler emerged in 2004 so there has been "slightly" more time to develop S/SD/RSDL. Despite this Linus said that anyone can prove him wrong by showing that SD/whatever is superior to CFS (and will be maintained with equal quality).

----------

## Dralnu

 *Paapaa wrote:*   

>  *Dralnu wrote:*   Didn't Ingo start out taking all the credit for himself? I think the big problem with the whole SD vs. CFS debate was that Ingo seemed to rewrite Con's work, took credit for it to begin with, and after some pressure gave some credit to Con.  
> 
> You are totally wrong here. Have you read the first announcement of CFS? I'll quote it for you:
> 
>  *Ingo Molnar wrote:*   i'd like to give credit to Con Kolivas for the general approach here:
> ...

 

Like I said, I had heard he did. We also have to figure that Con's work didn't get as much attention from users as Ingo's work has, and hence the chances for bugs to be found were substantially less. 3 years w/ 300 users will probably mean fewer bugs found then 6 months with 3000 users, and kernel testers trying to break your work.

Exposure does make a diffrence, as well.

----------

## barophobia

 *Dralnu wrote:*   

> 
> 
> Con did alot of good work, got stonewalled, end of story. It doesn't matter so much which is better - Ingo stole Con's work, and used his position to get his merged instead. You have no way of knowing whether or not the SD would have outworked CFS in the long-run, nor does anyone else now. The fact that it doesn't even seem that Linus or Ingo even really gave Con's work any real second look is kind of annoying (and arrogant), and has such uncovered (at least moreso) the kind of path the kernel is taking.
> 
> 

 

Con might have been just ignored by Linus since when do people look at old projects that are showing relatively slow development speed?  It might have been for political or personal reasons why SD got canned.  But this is life when managing such a large project people's feelings are going to get hurt no matter what.  Ingo might just happened to come up with the same solution as Con with out even realizing it.  This is not impossible, Leibniz and Newton did independent development of calculus but Newton is usually credited for it.

----------

## zeek

 *barophobia wrote:*   

> Ingo might just happened to come up with the same solution as Con with out even realizing it.  This is not impossible, Leibniz and Newton did independent development of calculus but Newton is usually credited for it.

 

Its totally impossible.  Ingo "reviewed" and "rejected" every one of Con's SD patch submissions.

----------

## barophobia

 *zeek wrote:*   

> Its totally impossible.  Ingo "reviewed" and "rejected" every one of Con's SD patch submissions.

 

If this is the case he should have at least given Con credit.  Not many things in the world is completely revolutionary and unique, but one should always give credit when building upon someone else's work.

Since haven't read the details of both schedulers I can not come to a conclusion of if there is any significant difference between them.

----------

## Paapaa

 *barophobia wrote:*   

>  *zeek wrote:*   Its totally impossible.  Ingo "reviewed" and "rejected" every one of Con's SD patch submissions. 
> 
> If this is the case he should have at least given Con credit. 

 

Ingo gave Con credit. Read this thread.

----------

## barophobia

 *Paapaa wrote:*   

>  *barophobia wrote:*    *zeek wrote:*   Its totally impossible.  Ingo "reviewed" and "rejected" every one of Con's SD patch submissions. 
> 
> If this is the case he should have at least given Con credit.  
> 
> Ingo gave Con credit. Read this thread.

 

Opps sorry about that, i know he gave credit and it is all good... This is why you should never post 5min after waking up.

----------

## zeek

The gist is not about credit or stealing concepts or re-implementing someone else's fully working solution.  The end result is that Ingo drove Con from Kernel development by his attitude and actions.

The reason this is bad is that Ingo originally thought there was nothing wrong with the O(1) scheduler that linux currently uses.  Con spearheaded and drove the "lets get an improved scheduler in linux" campaign for over a year!  Ingo wanted status quo.  He didn't want a new scheduler, he saw nothing wrong with the current scheduler.  It took Con over 1 year to convince Linus and Ingo that the O(1) scheduler was insufficient.  The kicker is when finally convinced they insult him and re-implement his work.

The guy who wanted status quo has won.  Sure we got an improved scheduler this time, but someone with drive who wants to make things better has moved on to something else.  The code quality between SD and CFS is irrelevant.  Linux lost an innovator -- this is the problem.

----------

