CFS to be merged in 2.6.23!

Message

jsf_x35a · Post by **jsf_x35a** » Wed Jul 11, 2007 1:38 am

Am I the only one excited?

Genewb · Post by **Genewb** » Wed Jul 11, 2007 1:44 am

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

Every change I make seems snappier. More a matter of wishful thinking and confirmation bias than real performance improvements, methinks.

jsf_x35a · Post by **jsf_x35a** » Fri Jul 13, 2007 12:29 am

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 · Post by **SiberianSniper** » Fri Jul 13, 2007 12:48 am

meh, I prefer SD

jsf_x35a · Post by **jsf_x35a** » Fri Jul 13, 2007 4:24 am

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 · Post by **SiberianSniper** » Fri Jul 13, 2007 4:27 am

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 · Post by **zeek** » Fri Jul 13, 2007 7:37 am

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 · Post by **mudrii** » Fri Jul 13, 2007 7:49 am

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

kernelOfTruth · Post by **kernelOfTruth** » Fri Jul 13, 2007 11:12 am

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

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

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

Paapaa · Post by **Paapaa** » Fri Jul 13, 2007 12:07 pm

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

zeek · Post by **zeek** » Sat Jul 14, 2007 12:22 am

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.

Great quote from that thread btw:

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

lagalopex · Post by **lagalopex** » Sat Jul 14, 2007 9:54 am

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 · Post by **Paapaa** » Sat Jul 14, 2007 9:57 am

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 · Post by **lagalopex** » Sat Jul 14, 2007 10:00 am

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

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 · Post by **Dominique_71** » Sun Jul 22, 2007 2:02 pm

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 · Post by **kernelOfTruth** » Mon Jul 23, 2007 11:57 am

/
From Con Kolivas <>
Subject Re: -mm merge plans for 2.6.23
Date Tue, 24 Jul 2007 10:08:19 +1000
Digg This

On Tuesday 10 July 2007 20:15, Con Kolivas wrote:
> On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
> > When replying, please rewrite the subject suitably and try to Cc: the
> > appropriate developer(s).
>
> ~swap prefetch
>
> Nick's only remaining issue which I could remotely identify was to make it
> cpuset aware:
> http://marc.info/?l=linux-mm&m=117875557014098&w=2
> as discussed with Paul Jackson it was cpuset aware:
> http://marc.info/?l=linux-mm&m=117895463120843&w=2
>
> I fixed all bugs I could find and improved it as much as I could last
> kernel cycle.
>
> Put me and the users out of our misery and merge it now or delete it
> forever please. And if the meaningless handwaving that I 100% expect as a
> response begins again, then that's fine. I'll take that as a no and you can
> dump it.

The window for 2.6.23 has now closed and your position on this is clear. I've
been supporting this code in -mm for 21 months since 16-Oct-2005 without any
obvious decision for this code forwards or backwards.

I am no longer part of your operating system's kernel's world; thus I cannot
support this code any longer. Unless someone takes over the code base for
swap prefetch you have to assume it is now unmaintained and should delete it.

Please respect my request to not be contacted further regarding this or any
other kernel code.

--
-ck

so swap prefetch wasn't merged into .23 ?

man those guys SUCK

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

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

it seems so

Sachankara · Post by **Sachankara** » Mon Jul 23, 2007 12:16 pm

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 · Post by **charlieg** » Wed Aug 01, 2007 10:22 pm

I wrote an article on this:
http://freegamer.blogspot.com/2007/07/d ... livas.html

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

Paapaa · Post by **Paapaa** » Wed Aug 01, 2007 10:40 pm

charlieg wrote:I wrote an article on this:
http://freegamer.blogspot.com/2007/07/d ... livas.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 · Post by **kernelOfTruth** » Wed Aug 01, 2007 11:33 pm

CFS is also said to scale better than SD.

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

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)

but I think that will be all fixed in .23

Dralnu · Post by **Dralnu** » Wed Aug 01, 2007 11:49 pm

Paapaa wrote:
charlieg wrote:I wrote an article on this:
http://freegamer.blogspot.com/2007/07/d ... livas.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.

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 · Post by **Paapaa** » Thu Aug 02, 2007 8:13 am

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 · Post by **Dralnu** » Thu Aug 02, 2007 11:45 pm

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

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 · Post by **barophobia** » Fri Aug 03, 2007 3:52 pm

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 · Post by **zeek** » Sat Aug 04, 2007 4:37 am

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.

CFS to be merged in 2.6.23!

CFS to be merged in 2.6.23!

Re: CFS to be merged in 2.6.23!