Re: [ck] Re: Linus 2.6.23-rc1
> two weeks stale, but your take on the EVMS story is incorrect. The > EVMS developers (that is, Kevin) sent out a nice, conciliatory email, > the project sputtered on for a while, then basically died. This is perfectly normal. It was outevolved and ran out of people who cared enough to continue it. Happens all the time. In the proprietary world its normally one company putting another out of business and lots of people losing jobs and money so its actually a good deal friendlier this side of the fence When you contribute to a big project some of your stuff will get nowhere, other stuff will eventually get kicked out and replaced. Its part of the progress of the system. And yes one day the Linux kernel will probably go the same was as EVMS when something cooler and neater replaces it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Saturday 28 July 2007 14:06, Diego Calleja wrote: > El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) escribió: > The main problem is clearly that no scheduler was clearly better than > the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - > both of them were good enought, but only one of them could be merged. > The difference is that EVMS developers didn't get that annoyed, and > not only they didn't quit but they continued developing their > userspace tools to make it work with the solution included in the > kernel > > (http://lwn.net/Articles/14714/) Not that I want to be in this thread, particularly since it is already two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. http://marc.info/?l=evms-devel=118240945708775=2 Bill is right. People who know people are right. A lot of good talent has been lost to Linux over the years because of various, perhaps good intentioned, gaffs. The thing is, if you contribute to a project like Linux for fun, when it stops being fun you walk. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Saturday 28 July 2007 14:06, Diego Calleja wrote: El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) escribió: The main problem is clearly that no scheduler was clearly better than the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both of them were good enought, but only one of them could be merged. The difference is that EVMS developers didn't get that annoyed, and not only they didn't quit but they continued developing their userspace tools to make it work with the solution included in the kernel (http://lwn.net/Articles/14714/) Not that I want to be in this thread, particularly since it is already two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. http://marc.info/?l=evms-develm=118240945708775w=2 Bill is right. People who know people are right. A lot of good talent has been lost to Linux over the years because of various, perhaps good intentioned, gaffs. The thing is, if you contribute to a project like Linux for fun, when it stops being fun you walk. Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. This is perfectly normal. It was outevolved and ran out of people who cared enough to continue it. Happens all the time. In the proprietary world its normally one company putting another out of business and lots of people losing jobs and money so its actually a good deal friendlier this side of the fence When you contribute to a big project some of your stuff will get nowhere, other stuff will eventually get kicked out and replaced. Its part of the progress of the system. And yes one day the Linux kernel will probably go the same was as EVMS when something cooler and neater replaces it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter whose code gets merged!
On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote: > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > [...] > > It does not matter [whose] code gets merged. > > What matters is that the problem gets solved and that the Linux > > kernel innovates forward. > > [...] > > This attitude has risks over the long term, if outsiders with fresh > ideas are discouraged. Risking becoming known to defer too much to > established maintainers, those fresh ideas may stop coming to linux. Amen to that, Frank. Driving off talented contributers is a Very Bad Thing for Linux in the long run. This will not not stop evolutionary progress, but it slows it down and may result in an overly inbred animal. It is especially easy to drive off a contributor whose day job is not Linux hacking. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter whose code gets merged!
On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote: Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. Amen to that, Frank. Driving off talented contributers is a Very Bad Thing for Linux in the long run. This will not not stop evolutionary progress, but it slows it down and may result in an overly inbred animal. It is especially easy to drive off a contributor whose day job is not Linux hacking. Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Hi - > My concern is that only "get my line of code merged" is seen as "the > ultimate thing". It's more than that. Linux is about collaboration [...] Unfortunately, this spirit of collaboration sometimes gets lost in practice when feedback is asymmetric, obnoxious, or absent. - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven <[EMAIL PROTECTED]> writes: > [...] > It does not matter [whose] code gets merged. > What matters is that the problem gets solved and that the Linux kernel > innovates forward. > [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote: > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > > [...] > > It does not matter [whose] code gets merged. > > What matters is that the problem gets solved and that the Linux kernel > > innovates forward. > > [...] > > This attitude has risks over the long term, if outsiders with fresh > ideas are discouraged. Risking becoming known to defer too much to > established maintainers, those fresh ideas may stop coming to linux. My concern is that only "get my line of code merged" is seen as "the ultimate thing". It's more than that. Linux is about collaboration, where it matters more that people work together to solve a problem, far far more than who actually types the lines in on the keyboard. Working on the problem should be seen (and recognized) as the right thing. Who writes the code is secundary to that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote: > I've had several cases myself where I spent quite some time solving a > problem, just to get some random remark from someone smart on lkml > saying "if you had done you would have had simple and superior solution>". Was I pissed off that my patch didn't > get merged but that this better approach got picked? NO! The problem > that I needed to solve got solved in a really good way. Mission > accomplished. Hey to me it even happened I had this nice and safe pte-highmem patch but the buggy highpte was merged instead, go figure. Con got lucky. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote: I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. Hey to me it even happened I had this nice and safe pte-highmem patch but the buggy highpte was merged instead, go figure. Con got lucky. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote: Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. My concern is that only get my line of code merged is seen as the ultimate thing. It's more than that. Linux is about collaboration, where it matters more that people work together to solve a problem, far far more than who actually types the lines in on the keyboard. Working on the problem should be seen (and recognized) as the right thing. Who writes the code is secundary to that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Hi - My concern is that only get my line of code merged is seen as the ultimate thing. It's more than that. Linux is about collaboration [...] Unfortunately, this spirit of collaboration sometimes gets lost in practice when feedback is asymmetric, obnoxious, or absent. - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote: > > > And, from a standpoint of ONGOING, long-term innovation: what matters > > > is that brilliant, new ideas get rewarded one way or another. > > > > and in this case, the reward is that the idea got used and credit was > > given > > You mean, when Ingo announced CFS he mentioned Con's name? and put his name in the code too > When you said "it does not matter whose code got merged", I have to > disagree. Sure, for the Linux community as a whole, for Linux itself, > it may not matter, but for the individuals involved, it does. And I > think benefits of individuals are as important as benefits of the > community (or the nation). I agree it's a nice ego boost to see your code merged. But... do you care more about your ego boost or about your problem getting solved? I really want to change this if you say "ego for code merging"... "ego boost for getting linux improved and being involved in solving an important problem" is a lot better type of ego boost.. No developer can or should expect that most, or even half of his code to be merged. Even Linus doesn't get half the code he writes into linux :) Con did get a whole bunch of stuff merged over the years, and for the rest he mostly got the problem solved. That's pretty successful -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
> > And, from a standpoint of ONGOING, long-term innovation: what matters > > is that brilliant, new ideas get rewarded one way or another. > > and in this case, the reward is that the idea got used and credit was > given You mean, when Ingo announced CFS he mentioned Con's name? I really doubt that is the best reward for a developer. > > Because if you don't, the people with the 'different' ideas walk away, > > you end up with only those who 'fit' the culture, and there goes innovation. > > yet at the same time if people walk away just because their code didn't > get used, even though their problem got solved, should we merge "worse" > code just to prevent that ? That's almost blackmail, and also just > stupid. > > (not suggesting that SD in this case was better or worse, just trying > to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said "it does not matter whose code got merged", I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not "grab the food right under other's nose" blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 10:14 +0200, [EMAIL PROTECTED] wrote: > On 8/1/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > Let me repeat the key message: > > > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > > > What matters is that the problem gets solved and that the Linux kernel > > innovates forward. > > And, from a standpoint of ONGOING, long-term innovation: what matters > is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given > Because > if you don't, the people with the 'different' ideas walk away, you end > up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge "worse" code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) > That's why I tried to get involved in this discussion. It doesn't > matter who's code gets merged. But it does matter that people get > scared away. It took the kernel folks a few years, but they managed to > get someone kicked out who's not 'in-crowd', who clearly has a > different view, and who has the intent and motivation to write and > maintain code. And he did manage to get some of his code in, just not all. He also managed to get people interested in his problem so much that a healthy stint of competition happened and his problem got solved. If people walk away because they don't 100% always get things done EXACTLY their way.. well so be it. > Of course that's 'overdone', but it conveys a point: If you focus too > much on exploiting current code, instead of fundamentally exploring > new ideas you go down in the long run. here's the thing. Fair scheduling DID get explored. deeply so. now, getting people interested in your problem (and that is needed to get them to pay attention to it) is a sales job, no ifs and buts there. You need to convince them that 1) the problem is real, 2) the problem is relevant. If you also have a proposed solution you also need to convince them that 3) the solution solves the problem and 4) that it's the right way to solve the problem. That isn't politics, it's part of how the ecosystem works; people are not stupid, but you need to convince them about your problem and solution. And that "default a bit skeptical and overworked" approach is the foundation of the process; the same way as you need to pass a code review before people will merge your code. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
> has to get the blessing of the maintainer. On the other hand, > as you just said, the maintainer has no such obligation. Umm nope. As a maintainer if you feed Linus stuff you wrote that he thinks is a bad idea it will not go in, and you'll get an explanation of why. The process isn't perfect (eg removing half-vanished maintainers isnt handled well) but it isn't as you claim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Jul 28 2007 12:34, Linus Torvalds wrote: >On Sat, 28 Jul 2007, Jan Engelhardt wrote: >> >> Time to investigate... Well it really is different. Simple test: - run Unreal Tournament 99 (nice 0, it gets 98%,99% CPU most of the time) - in a shell, `renice 20 $$; while :; do date; done;` The shell only produces one or two outputs per second. This seems different from the old-2.6 behavior, where a nice-20 process seemed to get a bit more share. (Due to interactivity bonus) Does anyone have a cpu hog test program that spreads its cpu time over the second rather than doing 300 ms wake and 700 ms sleep cycles after another? >Well, one thing that would be worth doing is to simply create a trace of >time-slices for both schedulers. > >It could easily be some hacky thing that just saves the process name and >TSC at each scheduling event in some fairly small fixed-sized per-CPU >circular buffer, and have a /sys interface that reads it out, and then you >do > > sleep 60 ; cat /sys/cpubuffer > buffer > >and play the game for 60 seconds (so that you get a buffer that represents >perhaps the last 10 seconds of play). Send me patches, I run the test. >It could *literally* just be an effect of the time quanta used, and CFS >just deciding that it's not interactive and giving things too long of a >CPU slice. > >Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to >tweak, but maybe there's some misfeature there, or maybe the default is >just bad for games, or whatever. > >Ingo: that sysctl_sched_granularity initialization doesn't make sense. You >talk about it being in units of nanoseconds, but then you do > > 20ULL/HZ > >which is nonsensical. That value is "2 seconds" (not 2ms like the comment >says) in nanoseconds, but then divided by HZ, so what's the meaning of >that HZ thing? Nothing in the scheduler should care about jiffies, why is >that related to HZ? All the scheduler clocks are in ns. > > Linus > Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On 8/1/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > Let me repeat the key message: > > It does not matter who's code gets merged. > It does not matter who's code gets merged. > It does not matter who's code gets merged. > It does not matter who's code gets merged. > > What matters is that the problem gets solved and that the Linux kernel > innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And that's bad. I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. There has to be a balance. And in some area's of the kernel, there seems to be a good balance - new ideas come in, code is being re-factored. But in scheduling and VM, I wonder if there's enough exploration... I hear 'We don't do politics' a lot in the kernel community. Well, what are politics? Managing the way code gets into the kernel? That's important for sure, right? And what about thinking about the hacker culture? Nobody would object to preserving and securing that. But those are not just technical matters. Yet they require thought. If the kernel culture doesn't work, the code won't work. There is a delicate balance, and a key part of what Linus has been doing is preserving it. I think he must not ignore that there is always room for improvement, and moments like these (where a big 'fight' is going on, and there is a clear sense of urgency about the matter) are the perfect times for a good discussion, and possible change. Use it. Love, Jos * Disclaimer: - I'm no kernel hacker - actually I help at the KDE project in the area of marketing... - yet, i have followed Con and his stuff for years - and I do research in the area of promoting innovation in organisations at a Dutch research institute, which is why I so annoyingly think I might have something to say. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying "if you had done you would have had ". Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the "which is likely to be maintained best" arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote: > > Did Ingo have the obligation to improve Con's work? Definitely not. > > Did Con have a right to get Ingo's improvements or > > suggestions? Definitely not. > > Yes, and that's where the inequality is. > > Unless the maintainer does a really bad job or pisses off Linus, > anyone who wants to merge his code into mainline pretty much > has to get the blessing of the maintainer. On the other hand, > as you just said, the maintainer has no such obligation. I think a lot of people are missing some key things here: It does not matter who's code gets merged. The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast improvement mode, and competed on all fronts and borrowed heavily from eachother in terms of ideas that worked, and innovated to stay ahead. The end result is that both were good schedulers, and Linux won by getting the fruit of this competition. Think of it as a mini-evolution of scheduler ideas compressed into a short time period. Now compare this to a single patch without competition/the need to survive in the habitat, say the first SD or the first CFS patch whatever your poison is. If there had been no competition element, we would have ended up with either one of those, and it would have been not nearly as good as they both ended up as in the end. Who wrote the code is not relevant in the large picture, the fact that the problem at hand (2.6 scheduler behavior) got solved is. I wish people would focus less on who wrote the actual code that got merged in the end, and more on the problem that got solved People who care about the desktop should be happy that the scheduler improved a lot due to the competition where the two new schedulers were hair-close in most aspects. Again.. think about the problem being solved. Not who wrote the code or which of the competitive patches got merged in the end. Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying "if you had done you would have had ". Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the "which is likely to be maintained best" arguments) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
> Did Ingo have the obligation to improve Con's work? Definitely not. > Did Con have a right to get Ingo's improvements or > suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. > There are no such rights in this open source > development framework (TM). > > What Ingo did, I think, was what he wanted and he has the right to do > that. I think it's the maintainer's privilege, not right. > in the open source world, that which is superior (i.e. code, function, > not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I think it's the maintainer's privilege, not right. in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote: Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. I think a lot of people are missing some key things here: It does not matter who's code gets merged. The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast improvement mode, and competed on all fronts and borrowed heavily from eachother in terms of ideas that worked, and innovated to stay ahead. The end result is that both were good schedulers, and Linux won by getting the fruit of this competition. Think of it as a mini-evolution of scheduler ideas compressed into a short time period. Now compare this to a single patch without competition/the need to survive in the habitat, say the first SD or the first CFS patch whatever your poison is. If there had been no competition element, we would have ended up with either one of those, and it would have been not nearly as good as they both ended up as in the end. Who wrote the code is not relevant in the large picture, the fact that the problem at hand (2.6 scheduler behavior) got solved is. I wish people would focus less on who wrote the actual code that got merged in the end, and more on the problem that got solved People who care about the desktop should be happy that the scheduler improved a lot due to the competition where the two new schedulers were hair-close in most aspects. Again.. think about the problem being solved. Not who wrote the code or which of the competitive patches got merged in the end. Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the which is likely to be maintained best arguments) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the which is likely to be maintained best arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On 8/1/07, Arjan van de Ven [EMAIL PROTECTED] wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And that's bad. I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. There has to be a balance. And in some area's of the kernel, there seems to be a good balance - new ideas come in, code is being re-factored. But in scheduling and VM, I wonder if there's enough exploration... I hear 'We don't do politics' a lot in the kernel community. Well, what are politics? Managing the way code gets into the kernel? That's important for sure, right? And what about thinking about the hacker culture? Nobody would object to preserving and securing that. But those are not just technical matters. Yet they require thought. If the kernel culture doesn't work, the code won't work. There is a delicate balance, and a key part of what Linus has been doing is preserving it. I think he must not ignore that there is always room for improvement, and moments like these (where a big 'fight' is going on, and there is a clear sense of urgency about the matter) are the perfect times for a good discussion, and possible change. Use it. Love, Jos * Disclaimer: - I'm no kernel hacker - actually I help at the KDE project in the area of marketing... - yet, i have followed Con and his stuff for years - and I do research in the area of promoting innovation in organisations at a Dutch research institute, which is why I so annoyingly think I might have something to say. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Jul 28 2007 12:34, Linus Torvalds wrote: On Sat, 28 Jul 2007, Jan Engelhardt wrote: Time to investigate... Well it really is different. Simple test: - run Unreal Tournament 99 (nice 0, it gets 98%,99% CPU most of the time) - in a shell, `renice 20 $$; while :; do date; done;` The shell only produces one or two outputs per second. This seems different from the old-2.6 behavior, where a nice-20 process seemed to get a bit more share. (Due to interactivity bonus) Does anyone have a cpu hog test program that spreads its cpu time over the second rather than doing 300 ms wake and 700 ms sleep cycles after another? Well, one thing that would be worth doing is to simply create a trace of time-slices for both schedulers. It could easily be some hacky thing that just saves the process name and TSC at each scheduling event in some fairly small fixed-sized per-CPU circular buffer, and have a /sys interface that reads it out, and then you do sleep 60 ; cat /sys/cpubuffer buffer and play the game for 60 seconds (so that you get a buffer that represents perhaps the last 10 seconds of play). Send me patches, I run the test. It could *literally* just be an effect of the time quanta used, and CFS just deciding that it's not interactive and giving things too long of a CPU slice. Yes, it's what /proc/sys/kernel/sched_granularity_ns is supposed to tweak, but maybe there's some misfeature there, or maybe the default is just bad for games, or whatever. Ingo: that sysctl_sched_granularity initialization doesn't make sense. You talk about it being in units of nanoseconds, but then you do 20ULL/HZ which is nonsensical. That value is 2 seconds (not 2ms like the comment says) in nanoseconds, but then divided by HZ, so what's the meaning of that HZ thing? Nothing in the scheduler should care about jiffies, why is that related to HZ? All the scheduler clocks are in ns. Linus Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. Umm nope. As a maintainer if you feed Linus stuff you wrote that he thinks is a bad idea it will not go in, and you'll get an explanation of why. The process isn't perfect (eg removing half-vanished maintainers isnt handled well) but it isn't as you claim. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 10:14 +0200, [EMAIL PROTECTED] wrote: On 8/1/07, Arjan van de Ven [EMAIL PROTECTED] wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge worse code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And he did manage to get some of his code in, just not all. He also managed to get people interested in his problem so much that a healthy stint of competition happened and his problem got solved. If people walk away because they don't 100% always get things done EXACTLY their way.. well so be it. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. here's the thing. Fair scheduling DID get explored. deeply so. now, getting people interested in your problem (and that is needed to get them to pay attention to it) is a sales job, no ifs and buts there. You need to convince them that 1) the problem is real, 2) the problem is relevant. If you also have a proposed solution you also need to convince them that 3) the solution solves the problem and 4) that it's the right way to solve the problem. That isn't politics, it's part of how the ecosystem works; people are not stupid, but you need to convince them about your problem and solution. And that default a bit skeptical and overworked approach is the foundation of the process; the same way as you need to pass a code review before people will merge your code. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given You mean, when Ingo announced CFS he mentioned Con's name? I really doubt that is the best reward for a developer. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge worse code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said it does not matter whose code got merged, I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not grab the food right under other's nose blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote: And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given You mean, when Ingo announced CFS he mentioned Con's name? and put his name in the code too When you said it does not matter whose code got merged, I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). I agree it's a nice ego boost to see your code merged. But... do you care more about your ego boost or about your problem getting solved? I really want to change this if you say ego for code merging... ego boost for getting linux improved and being involved in solving an important problem is a lot better type of ego boost.. No developer can or should expect that most, or even half of his code to be merged. Even Linus doesn't get half the code he writes into linux :) Con did get a whole bunch of stuff merged over the years, and for the rest he mostly got the problem solved. That's pretty successful -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that "Happiness is a choice, not a state." And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi, On Sat, 28 Jul 2007, Linus Torvalds wrote: > We've had people go with a splash before. Quite frankly, the current > scheduler situation looks very much like the CML2 situation. Anybody > remember that? The developer there also got rejected, the improvement was > made differently (and much more in line with existing practices and > maintainership), and life went on. Eric Raymond, however, left with a > splash. Since I was directly involved I'd like to point out a key difference. http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and initially I didn't plan on writing a new config system. At the beginning there was only the converter, which I did to address the issue that Eric created a complete new and different config database, so the converter was meant to create a more acceptable transition path. What happened next is that I haven't got a single response from Eric, so I continued hacking on it until was complete. The key difference is now that Eric refused the offered help, while Con was refused the help he needed to get his work integrated. When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: "I use this system in this way and it does not fair well with cfs!" Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Tue, 31 Jul 2007, Bill Huey wrote: > > Here's the problem, *a lot* of folks can do scheduler development in and > outside community, so what's with exclusive-only attitude towards the > scheduler ? There is no exclusive-only attitude towards the scheduler. If you send me small and obvious improvements, they'll get applied to the scheduler, exactly the same way they get applied to anything else. And if you try to rewrite everything, and do it on your own, and then don't even send me a patch, it also won't get applied. Surprise? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* Bill Huey <[EMAIL PROTECTED]> wrote: > Here's the problem, *a lot* of folks can do scheduler development in > and outside community, so what's with exclusive-only attitude towards > the scheduler ? You came to us as an ex-BSD developer (which has a completely different contribution culture) and early on i tried to explain to you (and we met in person at OLS2004) that the Linux way of getting code upstream is not that of social-engineering or talking the code upstream, but that of _coding_ your stuff upstream: working with others and getting good code accepted. I'm not sure you ever realized that point. To counter your myth of "upstream development exclusivity", here are some git-provided hard numbers. Since 2.6.22 was released 3 weeks ago, over half a million lines of code were added/modified/removed in the upstream -git kernel: 5965 files changed, 332689 insertions(+), 269500 deletions(-) that massive amount of work was done by over 750 contributors. Out of those 750 contributors, more than 160 are _first time contributors_. Think about it, there's _lots_ of fresh blood, about 650 new kernel contributors a year. The kernel/sched.c file itself, with 274 commits and 88 unique contributors over the past ~2 years alone is one of the most actively and most diversely developed core kernel subsystems in the kernel. Regarding PlugSched, i'd suggest you to read the detailed explanation that has been offered in this and in related discussions over the past few years on lkml. (see: http://lkml.org/lkml/2007/4/15/124 and http://lkml.org/lkml/2007/4/15/64 and many other postings) To recap: we dont have a pluggable TCP/IP core either. Nor do we have a pluggable MM. Pluggable I/O schedulers are not an unconditional success either - Nick (I/O scheduler author) recently stated that and suggested the CPU scheduler to not be pluggable. Whether something becomes pluggable or not depends on many _technological_ factors but you appear to be dead-set on spinning _any_ technical decision against pluggability into a conjured-up non-sequitor non-technical "so this means you have an exclusive-only attitude" position. Why do you do that? Why cannot you accept the plain fact that: _in a kernel, some things should not be pluggable_ Simple as that. I am still in favor of PlugSched as a nice external patch because it keeps people interested in schedulers and keeps the competitive pressure up even higher (and other reasons), but there are _stronger factors than that_ against its inclusion into mainline. (see those many mails about those factors) Besides the technological advantages, the competitive pressure can be _even higher_ if the 'competition' is not in-tree but out-of-tree - and the end result is an ultimately better scheduler. Had we not rejected PlugSched 4 years ago CFS could easily never have happened. We'd have 2-3 mediocre schedulers, instead of one good scheduler and _users_ would resist the removal of any of those schedulers, so no clear winner could ever gain enough momentum and Linux would forever be stuck with a stupid and inferior "you have to tweak the scheduler selection manually to your workload to get the max out of the system" handicap. But ... i can also understand it that you as a _person_ are unhappy: You were quite unhappy and bitter about me not including your lockstat patch in -rt, while all that happened was that for months i (and others) told you that the lockstat idea is nice and sound and tried to point it out to you how much simpler and more elegant it would be to use the lockdep infrastructure for the same purpose and tried to encourage you to pick that route. Peter Zijlstra implemented that approach meanwhile, and he used around a magnitude less code than your patch did. That code is upstream now. _You_ could have been the one who did that, and it was you who prevented yourself from having done that major contribution to Linux lock instrumentation. Perhaps partly influenced by your negative lockstat experience, you were also the first one who brought up the (pretty bogus) "elitist" "old guard" argument [ http://lkml.org/lkml/2007/4/14/115 ] as a reply to my initial CFS announcement, and shortly after your mail Con wrote his infamous outburst against CFS [ http://lkml.org/lkml/2007/4/14/199 ], to which you came up with another bogus "the main failure I see here is that Con wasn't included in this design or privately in review process" reply [ http://lkml.org/lkml/2007/4/15/4 ] that only fanned the flames. I believe by doing so you poured the oil of your own bitterness on his fire, thinly masked as neutral constructive criticism. So in my opinion you are far from being an unbiased observer in this matter, you keep repeating your old arguments without apparently listening to the replies and thus i doubt anything i say could really make you 'happy' :-/ Really, i'd love it if you started contributing to Linux in a major way,
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, 2007-07-31 at 02:57 -0700, Bill Huey wrote: > On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: > > > > We obviously all saw how the particular authors tried to address the > > issues. Ingo tried to address all concerns while Con simply ranted about > > his scheduler being better. If this is what you think about being a bit > > more human, then I think that this has no place in the lkml. > > That's highly inaccurate and rather disrespect of Con's experience. > There as a policy decision made with SD that one person basically didn't > like, this person whined like a baby for the a formula bottle and didn't > understand how to use "nice" to control this inherent behavior of this > scheduler. Chuckle. You are really desperate for entertainment. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote: > Ingo posted numbers. Look at those numbers, and then I would suggest some > people could seriously consider just shutting up. I've seen too many > idiotic people who claim that Con got treated unfairly, without those > people admitting that maybe I had a point when I said that we have had a > scheduler maintainer for years that actually knows what he's doing. Here's the problem, *a lot* of folks can do scheduler development in and outside community, so what's with exclusive-only attitude towards the scheduler ? There's sufficient effort coming from folks working on CFS from many sources so how's sched-plugin a *threat* to stock kernel scheduler development if it gets to the main tree as the default compile option ?? Those are the core question that Con brought in the APC article, folks are angry because and nobody central to the current Linux has address this and instead focused on a single narrow set of technical issues to justify a particular set of actions. I mean, I'm not the only that has said this so there has to be some kind of truth behind it. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: > And I think you are digressing from the main issue, which is the empirical > comparison of SD vs. CFS and to determine which is best. The root of all > the scheduler fuss was the emotional reaction of SD's author on why his > scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. > We obviously all saw how the particular authors tried to address the > issues. Ingo tried to address all concerns while Con simply ranted about > his scheduler being better. If this is what you think about being a bit > more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use "nice" to control this inherent behavior of this scheduler. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use nice to control this inherent behavior of this scheduler. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote: Ingo posted numbers. Look at those numbers, and then I would suggest some people could seriously consider just shutting up. I've seen too many idiotic people who claim that Con got treated unfairly, without those people admitting that maybe I had a point when I said that we have had a scheduler maintainer for years that actually knows what he's doing. Here's the problem, *a lot* of folks can do scheduler development in and outside community, so what's with exclusive-only attitude towards the scheduler ? There's sufficient effort coming from folks working on CFS from many sources so how's sched-plugin a *threat* to stock kernel scheduler development if it gets to the main tree as the default compile option ?? Those are the core question that Con brought in the APC article, folks are angry because and nobody central to the current Linux has address this and instead focused on a single narrow set of technical issues to justify a particular set of actions. I mean, I'm not the only that has said this so there has to be some kind of truth behind it. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, 2007-07-31 at 02:57 -0700, Bill Huey wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use nice to control this inherent behavior of this scheduler. Chuckle. You are really desperate for entertainment. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* Bill Huey [EMAIL PROTECTED] wrote: Here's the problem, *a lot* of folks can do scheduler development in and outside community, so what's with exclusive-only attitude towards the scheduler ? You came to us as an ex-BSD developer (which has a completely different contribution culture) and early on i tried to explain to you (and we met in person at OLS2004) that the Linux way of getting code upstream is not that of social-engineering or talking the code upstream, but that of _coding_ your stuff upstream: working with others and getting good code accepted. I'm not sure you ever realized that point. To counter your myth of upstream development exclusivity, here are some git-provided hard numbers. Since 2.6.22 was released 3 weeks ago, over half a million lines of code were added/modified/removed in the upstream -git kernel: 5965 files changed, 332689 insertions(+), 269500 deletions(-) that massive amount of work was done by over 750 contributors. Out of those 750 contributors, more than 160 are _first time contributors_. Think about it, there's _lots_ of fresh blood, about 650 new kernel contributors a year. The kernel/sched.c file itself, with 274 commits and 88 unique contributors over the past ~2 years alone is one of the most actively and most diversely developed core kernel subsystems in the kernel. Regarding PlugSched, i'd suggest you to read the detailed explanation that has been offered in this and in related discussions over the past few years on lkml. (see: http://lkml.org/lkml/2007/4/15/124 and http://lkml.org/lkml/2007/4/15/64 and many other postings) To recap: we dont have a pluggable TCP/IP core either. Nor do we have a pluggable MM. Pluggable I/O schedulers are not an unconditional success either - Nick (I/O scheduler author) recently stated that and suggested the CPU scheduler to not be pluggable. Whether something becomes pluggable or not depends on many _technological_ factors but you appear to be dead-set on spinning _any_ technical decision against pluggability into a conjured-up non-sequitor non-technical so this means you have an exclusive-only attitude position. Why do you do that? Why cannot you accept the plain fact that: _in a kernel, some things should not be pluggable_ Simple as that. I am still in favor of PlugSched as a nice external patch because it keeps people interested in schedulers and keeps the competitive pressure up even higher (and other reasons), but there are _stronger factors than that_ against its inclusion into mainline. (see those many mails about those factors) Besides the technological advantages, the competitive pressure can be _even higher_ if the 'competition' is not in-tree but out-of-tree - and the end result is an ultimately better scheduler. Had we not rejected PlugSched 4 years ago CFS could easily never have happened. We'd have 2-3 mediocre schedulers, instead of one good scheduler and _users_ would resist the removal of any of those schedulers, so no clear winner could ever gain enough momentum and Linux would forever be stuck with a stupid and inferior you have to tweak the scheduler selection manually to your workload to get the max out of the system handicap. But ... i can also understand it that you as a _person_ are unhappy: You were quite unhappy and bitter about me not including your lockstat patch in -rt, while all that happened was that for months i (and others) told you that the lockstat idea is nice and sound and tried to point it out to you how much simpler and more elegant it would be to use the lockdep infrastructure for the same purpose and tried to encourage you to pick that route. Peter Zijlstra implemented that approach meanwhile, and he used around a magnitude less code than your patch did. That code is upstream now. _You_ could have been the one who did that, and it was you who prevented yourself from having done that major contribution to Linux lock instrumentation. Perhaps partly influenced by your negative lockstat experience, you were also the first one who brought up the (pretty bogus) elitist old guard argument [ http://lkml.org/lkml/2007/4/14/115 ] as a reply to my initial CFS announcement, and shortly after your mail Con wrote his infamous outburst against CFS [ http://lkml.org/lkml/2007/4/14/199 ], to which you came up with another bogus the main failure I see here is that Con wasn't included in this design or privately in review process reply [ http://lkml.org/lkml/2007/4/15/4 ] that only fanned the flames. I believe by doing so you poured the oil of your own bitterness on his fire, thinly masked as neutral constructive criticism. So in my opinion you are far from being an unbiased observer in this matter, you keep repeating your old arguments without apparently listening to the replies and thus i doubt anything i say could really make you 'happy' :-/ Really, i'd love it if you started contributing to Linux in a major way, instead of doing
Re: Linus 2.6.23-rc1
On Tue, 31 Jul 2007, Bill Huey wrote: Here's the problem, *a lot* of folks can do scheduler development in and outside community, so what's with exclusive-only attitude towards the scheduler ? There is no exclusive-only attitude towards the scheduler. If you send me small and obvious improvements, they'll get applied to the scheduler, exactly the same way they get applied to anything else. And if you try to rewrite everything, and do it on your own, and then don't even send me a patch, it also won't get applied. Surprise? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: I use this system in this way and it does not fair well with cfs! Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi, On Sat, 28 Jul 2007, Linus Torvalds wrote: We've had people go with a splash before. Quite frankly, the current scheduler situation looks very much like the CML2 situation. Anybody remember that? The developer there also got rejected, the improvement was made differently (and much more in line with existing practices and maintainership), and life went on. Eric Raymond, however, left with a splash. Since I was directly involved I'd like to point out a key difference. http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and initially I didn't plan on writing a new config system. At the beginning there was only the converter, which I did to address the issue that Eric created a complete new and different config database, so the converter was meant to create a more acceptable transition path. What happened next is that I haven't got a single response from Eric, so I continued hacking on it until was complete. The key difference is now that Eric refused the offered help, while Con was refused the help he needed to get his work integrated. When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that Happiness is a choice, not a state. And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the "show me the numbers" argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 17:04 +0200, Ingo Molnar wrote: > hi Kasper, > > * Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > Im still not so keen about this, Ingo never did get CFS to match SD in > > smoothness for 3d applications, where my test subjects are quake(s), > > world of warcraft via wine, unreal tournament 2004. And this is > > despite many patches he sent me to try and tweak it. [...] > > hey, i thought you vanished from the face of the earth :-) The last > email i got from you was more than 2 months ago, where you said that > you'll try the latest CFS version as soon as possible but that you were > busy with work. I sent 2 more emails to you about new CFS versions but > then stopped pestering you directly - work _does_ take precedence over > games =B-) > I did respond to that one, but perhaps some mail have been getting lost, cause i cant find any more from you in my inbox. > CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went > upstream, there were no 3D related CFS regressions open for quite some > time and because i never heard back from you i assumed everything's > peachy. I must admit i havent tested the very very latest, will do > > In any case i'm glad you found the time to try CFS again, so please let > me know in what way it regresses. In your most recent emails you did not > indicate what specific problem you are having (and you did not reply to > my last emails from May) - are your old regression reports against CFS > v13 from May still true as of v2.6.23-rc1? If they are, could you please > indicate which specific report of yours describes it best and send me > (or upload to some webspace) the specific .config you are using on your > box, and the cfs-debug-info.sh snapshot taken when you are running your > game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest > quality debug output) You can pick the script up from: > > http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh > > Giving us that info would help us immensely with tracking down any CFS > problem you might still be having. Sure. > > Or, if you feel adventurous enough to look into the internals of the > kernel (which, considering your offer to take up SD maintenance, you > must be ;-), here's my kernel latency tracer: Well, im not sure how good i would be at maintaining SD, my idea was more or less just do the bare minimum to get the thing running on newer kernels :) > >http://people.redhat.com/mingo/latency-tracing-patches/ > > ( see: latency-tracer-v2.6.23-rc1-combo.patch ) > > the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set > /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to > thus measure raw worst-case scheduler latencies - if you regularly see > the kernel report above say 1000 usecs latencies to the syslog, on a > PREEMPT kernel then there's definitely something foul going on. For > example, that's how i found an audio playback latency problem in an > early version of CFS: > > (sshd-14614|#1): new 5 us maximum-latency wakeup. > ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. > ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. > (sshd-14614|#1): new 10 us maximum-latency wakeup. > ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. > (events/0-9|#0): new 789 us maximum-latency wakeup. > ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. > Actually, now that you mention ogg123, i've had some bugs on CFS with this, i thought it was an ogg123 bug, but now that i remember it its only on CFS i have it.. when i run multiple ogg123 instances, suddenly they will just stop playing and lock up. This happens when someone writes alot fast to me on kopete, where i use ogg123 to play a bling sound.. > that 2.5 msecs latency in the ogg123 task was definitely the sign of a > kernel bug. > > If plain WAKEUP_TIMING does not show anything suspicious, you can use > the latency tracer in more advanced ways as well to trace the whole > system and figure out the precise cause of your game latencies - i'll be > glad to help with that if no simpler measure helps. [see trace-it.c for > some of those details.] > > > [...] As far as im concerned, i may be forced to unofficially maintain > > SD for my own systems(allthough lots in the gaming community is bound > > to be interrested, as it does make games lots better) > > i'd encourage you to do it - in fact i already tried to prod Peter > Williams into doing exactly that ;) The more reality checks a scheduler > has, the better. [ Btw., after the obvious initial merging trouble it > should be much easier to keep SD maintained against future upstream > kernels due to the policy modularity that CFS introduces. (and which > policy-modularity should also help reduce the size and complexity of the > SD patch.) ] > > Thanks, > > Ingo > - > To
Re: Linus 2.6.23-rc1
* George Sescher <[EMAIL PROTECTED]> wrote: > > * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > i'd encourage you to do it - in fact i already tried to prod Peter > > > > > > Williams into doing exactly that ;) The more reality checks a > > > > > > scheduler has, the better. [ Btw., after the obvious initial merging > > > > > > trouble it should be much easier to keep SD maintained against > > > > > > future upstream kernels due to the policy modularity that CFS > > > > > > introduces. (and which policy-modularity should also help reduce the > > > > > > size and complexity of the SD patch.) ] > > > > > > > * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > You're advocating plugsched now? > > > > > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > hm, the way you posited this question implies that you see an > > > > inconsistency in my position or that it surprised you - i cannot explain > > > > the '' in any other way :) Which bit do you see as inconsistent > > > > and/or which bit surprised you and why? > > > > > > The idea is not good enough for mainline and has no place in mainline > > > yet you say it's very important to maintain it... but out of mainline. > > > Place the responsibility of keeping mainline's performance in check > > > "reality check as you called it" on to someone who is forced to > > > develop out of mainline? I have zero interest one way or the other > > > myself, but how can one not chuckle? > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > What you should realize is that _all_ future code that goes into Linux > > is 'forced' to be developed 'out of mainline' today. So what you seem to > > characterise via negative terms like 'forced', and what seems to make > > you 'chuckle' (not meant as a compliment either i gather ;), is in fact > > the _very engine_ that keeps Linux running. > > > > And there's no exception: Linus himself creates an "out of mainline" > > fork of Linux every time he develops something new. "Forks" are _the_ > > main mechanism to develop Linux, and it always was. External code is the > > "reality check" of mainline code. It is the 'external pool of genes' > > that is _competing_ against in-tree code. > > > > Sometimes the decision to include new bits of code is easy and positive > > (so it is a "fork" only very briefly and nobody actually ever has enough > > time to think of that code as a "fork"), sometimes it takes some time > > and the decision is positive, sometimes the decision is immediately > > negative and the code is rejected, sometimes it's negative after some > > time. Often code goes through several cycles of rejection before it is > > merged. The larger the code, the more rejections it will see - and that > > is natural. Sometimes, very rarely, out of the hundreds of thousands of > > external changes that went into Linux so far, code seems to be staying > > 'in limbo' forever - such as the kernel debugger. So _every_ color of > > the spectrum is present: immediate integration, immediate rejection, > > long-term integration, long-term rejection, ping-pong of rejections > > until integration, and even decisions that seem to take a near > > 'eternity' in very rare cases. > > > > If a biologist took a look at these gene pool dynamic parameters alone, > > without knowing a squat about kernel technology, the likely conclusion > > would be that this is "a healthy, diverse gene pool that is being > > affected by many many external factors. A true expert at survival, that > > critter!" ;-) > > > > For example, i'm at the moment maintaining in excess of 400 patches "out > > of mainline", many of which will never see the "daylight of upstream". > > Many of those are longer-term "reality checks" that could replace > > in-tree code in the future or are in the process of replacing in-tree > > code as we speak. Some are "reality checks" that _failed_ to replace > > in-tree code but i'm still maintaining them because i find them useful. > > If the kernel code that these patches modify happens to be modularized > > then it is sometimes helpful to my out-of-tree patches (and sometimes > > it's a pain) - but in any case, i dont "require" nor "suggest" upstream > > maintainers to modularize, just to make my "out of tree" life easier. > > Are they still useful to Linux in general? I sure hope so. > > > > It was always like this in Linux: modularization is mainly dictated by > > the needs of the in-tree code - and that's very much on purpose, and > > always was, to increase the advantages of including good external genes > > in the kernel gene pool. > > heh :) Sorry, but i have to disappoint you on that count :-) > Nope. I can't equate your soliloquy about the development process with > what it appears you are doing in the case of plugsched [...] could you please be a bit more specific - what do you mean under "what you are doing in the case
Re: Linus 2.6.23-rc1
> * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > i'd encourage you to do it - in fact i already tried to prod Peter > > > > > Williams into doing exactly that ;) The more reality checks a > > > > > scheduler has, the better. [ Btw., after the obvious initial merging > > > > > trouble it should be much easier to keep SD maintained against > > > > > future upstream kernels due to the policy modularity that CFS > > > > > introduces. (and which policy-modularity should also help reduce the > > > > > size and complexity of the SD patch.) ] > > > > > * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > You're advocating plugsched now? > > > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > hm, the way you posited this question implies that you see an > > > inconsistency in my position or that it surprised you - i cannot explain > > > the '' in any other way :) Which bit do you see as inconsistent > > > and/or which bit surprised you and why? > > > > The idea is not good enough for mainline and has no place in mainline > > yet you say it's very important to maintain it... but out of mainline. > > Place the responsibility of keeping mainline's performance in check > > "reality check as you called it" on to someone who is forced to > > develop out of mainline? I have zero interest one way or the other > > myself, but how can one not chuckle? On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > What you should realize is that _all_ future code that goes into Linux > is 'forced' to be developed 'out of mainline' today. So what you seem to > characterise via negative terms like 'forced', and what seems to make > you 'chuckle' (not meant as a compliment either i gather ;), is in fact > the _very engine_ that keeps Linux running. > > And there's no exception: Linus himself creates an "out of mainline" > fork of Linux every time he develops something new. "Forks" are _the_ > main mechanism to develop Linux, and it always was. External code is the > "reality check" of mainline code. It is the 'external pool of genes' > that is _competing_ against in-tree code. > > Sometimes the decision to include new bits of code is easy and positive > (so it is a "fork" only very briefly and nobody actually ever has enough > time to think of that code as a "fork"), sometimes it takes some time > and the decision is positive, sometimes the decision is immediately > negative and the code is rejected, sometimes it's negative after some > time. Often code goes through several cycles of rejection before it is > merged. The larger the code, the more rejections it will see - and that > is natural. Sometimes, very rarely, out of the hundreds of thousands of > external changes that went into Linux so far, code seems to be staying > 'in limbo' forever - such as the kernel debugger. So _every_ color of > the spectrum is present: immediate integration, immediate rejection, > long-term integration, long-term rejection, ping-pong of rejections > until integration, and even decisions that seem to take a near > 'eternity' in very rare cases. > > If a biologist took a look at these gene pool dynamic parameters alone, > without knowing a squat about kernel technology, the likely conclusion > would be that this is "a healthy, diverse gene pool that is being > affected by many many external factors. A true expert at survival, that > critter!" ;-) > > For example, i'm at the moment maintaining in excess of 400 patches "out > of mainline", many of which will never see the "daylight of upstream". > Many of those are longer-term "reality checks" that could replace > in-tree code in the future or are in the process of replacing in-tree > code as we speak. Some are "reality checks" that _failed_ to replace > in-tree code but i'm still maintaining them because i find them useful. > If the kernel code that these patches modify happens to be modularized > then it is sometimes helpful to my out-of-tree patches (and sometimes > it's a pain) - but in any case, i dont "require" nor "suggest" upstream > maintainers to modularize, just to make my "out of tree" life easier. > Are they still useful to Linux in general? I sure hope so. > > It was always like this in Linux: modularization is mainly dictated by > the needs of the in-tree code - and that's very much on purpose, and > always was, to increase the advantages of including good external genes > in the kernel gene pool. Nope. I can't equate your soliloquy about the development process with what it appears you are doing in the case of plugsched but you're obviously too smart for me to argue against or I don't understand and I've already overstepped my authority on this mailing list being an ordinary user. I'll just end up trying to extract your boot from my anus. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Linus 2.6.23-rc1
* George Sescher <[EMAIL PROTECTED]> wrote: > > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > i'd encourage you to do it - in fact i already tried to prod Peter > > > > Williams into doing exactly that ;) The more reality checks a > > > > scheduler has, the better. [ Btw., after the obvious initial merging > > > > trouble it should be much easier to keep SD maintained against > > > > future upstream kernels due to the policy modularity that CFS > > > > introduces. (and which policy-modularity should also help reduce the > > > > size and complexity of the SD patch.) ] > > > * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > > > > > You're advocating plugsched now? > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > hm, the way you posited this question implies that you see an > > inconsistency in my position or that it surprised you - i cannot explain > > the '' in any other way :) Which bit do you see as inconsistent > > and/or which bit surprised you and why? > > The idea is not good enough for mainline and has no place in mainline > yet you say it's very important to maintain it... but out of mainline. > Place the responsibility of keeping mainline's performance in check > "reality check as you called it" on to someone who is forced to > develop out of mainline? I have zero interest one way or the other > myself, but how can one not chuckle? What you should realize is that _all_ future code that goes into Linux is 'forced' to be developed 'out of mainline' today. So what you seem to characterise via negative terms like 'forced', and what seems to make you 'chuckle' (not meant as a compliment either i gather ;), is in fact the _very engine_ that keeps Linux running. And there's no exception: Linus himself creates an "out of mainline" fork of Linux every time he develops something new. "Forks" are _the_ main mechanism to develop Linux, and it always was. External code is the "reality check" of mainline code. It is the 'external pool of genes' that is _competing_ against in-tree code. Sometimes the decision to include new bits of code is easy and positive (so it is a "fork" only very briefly and nobody actually ever has enough time to think of that code as a "fork"), sometimes it takes some time and the decision is positive, sometimes the decision is immediately negative and the code is rejected, sometimes it's negative after some time. Often code goes through several cycles of rejection before it is merged. The larger the code, the more rejections it will see - and that is natural. Sometimes, very rarely, out of the hundreds of thousands of external changes that went into Linux so far, code seems to be staying 'in limbo' forever - such as the kernel debugger. So _every_ color of the spectrum is present: immediate integration, immediate rejection, long-term integration, long-term rejection, ping-pong of rejections until integration, and even decisions that seem to take a near 'eternity' in very rare cases. If a biologist took a look at these gene pool dynamic parameters alone, without knowing a squat about kernel technology, the likely conclusion would be that this is "a healthy, diverse gene pool that is being affected by many many external factors. A true expert at survival, that critter!" ;-) For example, i'm at the moment maintaining in excess of 400 patches "out of mainline", many of which will never see the "daylight of upstream". Many of those are longer-term "reality checks" that could replace in-tree code in the future or are in the process of replacing in-tree code as we speak. Some are "reality checks" that _failed_ to replace in-tree code but i'm still maintaining them because i find them useful. If the kernel code that these patches modify happens to be modularized then it is sometimes helpful to my out-of-tree patches (and sometimes it's a pain) - but in any case, i dont "require" nor "suggest" upstream maintainers to modularize, just to make my "out of tree" life easier. Are they still useful to Linux in general? I sure hope so. It was always like this in Linux: modularization is mainly dictated by the needs of the in-tree code - and that's very much on purpose, and always was, to increase the advantages of including good external genes in the kernel gene pool. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
> > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > i'd encourage you to do it - in fact i already tried to prod Peter > > > Williams into doing exactly that ;) The more reality checks a > > > scheduler has, the better. [ Btw., after the obvious initial merging > > > trouble it should be much easier to keep SD maintained against > > > future upstream kernels due to the policy modularity that CFS > > > introduces. (and which policy-modularity should also help reduce the > > > size and complexity of the SD patch.) ] > * George Sescher <[EMAIL PROTECTED]> wrote: > > > > > > You're advocating plugsched now? On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > hm, the way you posited this question implies that you see an > inconsistency in my position or that it surprised you - i cannot explain > the '' in any other way :) Which bit do you see as inconsistent > and/or which bit surprised you and why? The idea is not good enough for mainline and has no place in mainline yet you say it's very important to maintain it... but out of mainline. Place the responsibility of keeping mainline's performance in check "reality check as you called it" on to someone who is forced to develop out of mainline? I have zero interest one way or the other myself, but how can one not chuckle? Again I have no interest either way but if this is that important a reality check that it needs maintaining it should be oh I don't know, an -mm only feature or something? Please don't jump down my throat, your position just needs clarifying. :-| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* George Sescher <[EMAIL PROTECTED]> wrote: > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > i'd encourage you to do it - in fact i already tried to prod Peter > > Williams into doing exactly that ;) The more reality checks a > > scheduler has, the better. [ Btw., after the obvious initial merging > > trouble it should be much easier to keep SD maintained against > > future upstream kernels due to the policy modularity that CFS > > introduces. (and which policy-modularity should also help reduce the > > size and complexity of the SD patch.) ] > > > > You're advocating plugsched now? hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the '' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* George Sescher [EMAIL PROTECTED] wrote: On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] chuckle You're advocating plugsched now? hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the 'chuckle' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] * George Sescher [EMAIL PROTECTED] wrote: chuckle You're advocating plugsched now? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the 'chuckle' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? The idea is not good enough for mainline and has no place in mainline yet you say it's very important to maintain it... but out of mainline. Place the responsibility of keeping mainline's performance in check reality check as you called it on to someone who is forced to develop out of mainline? I have zero interest one way or the other myself, but how can one not chuckle? Again I have no interest either way but if this is that important a reality check that it needs maintaining it should be oh I don't know, an -mm only feature or something? Please don't jump down my throat, your position just needs clarifying. :-| - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* George Sescher [EMAIL PROTECTED] wrote: On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] * George Sescher [EMAIL PROTECTED] wrote: chuckle You're advocating plugsched now? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the 'chuckle' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? The idea is not good enough for mainline and has no place in mainline yet you say it's very important to maintain it... but out of mainline. Place the responsibility of keeping mainline's performance in check reality check as you called it on to someone who is forced to develop out of mainline? I have zero interest one way or the other myself, but how can one not chuckle? What you should realize is that _all_ future code that goes into Linux is 'forced' to be developed 'out of mainline' today. So what you seem to characterise via negative terms like 'forced', and what seems to make you 'chuckle' (not meant as a compliment either i gather ;), is in fact the _very engine_ that keeps Linux running. And there's no exception: Linus himself creates an out of mainline fork of Linux every time he develops something new. Forks are _the_ main mechanism to develop Linux, and it always was. External code is the reality check of mainline code. It is the 'external pool of genes' that is _competing_ against in-tree code. Sometimes the decision to include new bits of code is easy and positive (so it is a fork only very briefly and nobody actually ever has enough time to think of that code as a fork), sometimes it takes some time and the decision is positive, sometimes the decision is immediately negative and the code is rejected, sometimes it's negative after some time. Often code goes through several cycles of rejection before it is merged. The larger the code, the more rejections it will see - and that is natural. Sometimes, very rarely, out of the hundreds of thousands of external changes that went into Linux so far, code seems to be staying 'in limbo' forever - such as the kernel debugger. So _every_ color of the spectrum is present: immediate integration, immediate rejection, long-term integration, long-term rejection, ping-pong of rejections until integration, and even decisions that seem to take a near 'eternity' in very rare cases. If a biologist took a look at these gene pool dynamic parameters alone, without knowing a squat about kernel technology, the likely conclusion would be that this is a healthy, diverse gene pool that is being affected by many many external factors. A true expert at survival, that critter! ;-) For example, i'm at the moment maintaining in excess of 400 patches out of mainline, many of which will never see the daylight of upstream. Many of those are longer-term reality checks that could replace in-tree code in the future or are in the process of replacing in-tree code as we speak. Some are reality checks that _failed_ to replace in-tree code but i'm still maintaining them because i find them useful. If the kernel code that these patches modify happens to be modularized then it is sometimes helpful to my out-of-tree patches (and sometimes it's a pain) - but in any case, i dont require nor suggest upstream maintainers to modularize, just to make my out of tree life easier. Are they still useful to Linux in general? I sure hope so. It was always like this in Linux: modularization is mainly dictated by the needs of the in-tree code - and that's very much on purpose, and always was, to increase the advantages of including good external genes in the kernel gene pool. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* George Sescher [EMAIL PROTECTED] wrote: On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] * George Sescher [EMAIL PROTECTED] wrote: chuckle You're advocating plugsched now? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the 'chuckle' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? The idea is not good enough for mainline and has no place in mainline yet you say it's very important to maintain it... but out of mainline. Place the responsibility of keeping mainline's performance in check reality check as you called it on to someone who is forced to develop out of mainline? I have zero interest one way or the other myself, but how can one not chuckle? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: What you should realize is that _all_ future code that goes into Linux is 'forced' to be developed 'out of mainline' today. So what you seem to characterise via negative terms like 'forced', and what seems to make you 'chuckle' (not meant as a compliment either i gather ;), is in fact the _very engine_ that keeps Linux running. And there's no exception: Linus himself creates an out of mainline fork of Linux every time he develops something new. Forks are _the_ main mechanism to develop Linux, and it always was. External code is the reality check of mainline code. It is the 'external pool of genes' that is _competing_ against in-tree code. Sometimes the decision to include new bits of code is easy and positive (so it is a fork only very briefly and nobody actually ever has enough time to think of that code as a fork), sometimes it takes some time and the decision is positive, sometimes the decision is immediately negative and the code is rejected, sometimes it's negative after some time. Often code goes through several cycles of rejection before it is merged. The larger the code, the more rejections it will see - and that is natural. Sometimes, very rarely, out of the hundreds of thousands of external changes that went into Linux so far, code seems to be staying 'in limbo' forever - such as the kernel debugger. So _every_ color of the spectrum is present: immediate integration, immediate rejection, long-term integration, long-term rejection, ping-pong of rejections until integration, and even decisions that seem to take a near 'eternity' in very rare cases. If a biologist took a look at these gene pool dynamic parameters alone, without knowing a squat about kernel technology, the likely conclusion would be that this is a healthy, diverse gene pool that is being affected by many many external factors. A true expert at survival, that critter! ;-) For example, i'm at the moment maintaining in excess of 400 patches out of mainline, many of which will never see the daylight of upstream. Many of those are longer-term reality checks that could replace in-tree code in the future or are in the process of replacing in-tree code as we speak. Some are reality checks that _failed_ to replace in-tree code but i'm still maintaining them because i find them useful. If the kernel code that these patches modify happens to be modularized then it is sometimes helpful to my out-of-tree patches (and sometimes it's a pain) - but in any case, i dont require nor suggest upstream maintainers to modularize, just to make my out of tree life easier. Are they still useful to Linux in general? I sure hope so. It was always like this in Linux: modularization is mainly dictated by the needs of the in-tree code - and that's very much on purpose, and always was, to increase the advantages of including good external genes in the kernel gene pool. permission to jump down my throat granted now Nope. I can't equate your soliloquy about the development process with what it appears you are doing in the case of plugsched but you're obviously too smart for me to argue against or I don't understand and I've already overstepped my authority on this mailing list being an ordinary user. I'll just end up trying to extract your boot from my anus. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* George Sescher [EMAIL PROTECTED] wrote: * George Sescher [EMAIL PROTECTED] wrote: On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] * George Sescher [EMAIL PROTECTED] wrote: chuckle You're advocating plugsched now? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: hm, the way you posited this question implies that you see an inconsistency in my position or that it surprised you - i cannot explain the 'chuckle' in any other way :) Which bit do you see as inconsistent and/or which bit surprised you and why? The idea is not good enough for mainline and has no place in mainline yet you say it's very important to maintain it... but out of mainline. Place the responsibility of keeping mainline's performance in check reality check as you called it on to someone who is forced to develop out of mainline? I have zero interest one way or the other myself, but how can one not chuckle? On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: What you should realize is that _all_ future code that goes into Linux is 'forced' to be developed 'out of mainline' today. So what you seem to characterise via negative terms like 'forced', and what seems to make you 'chuckle' (not meant as a compliment either i gather ;), is in fact the _very engine_ that keeps Linux running. And there's no exception: Linus himself creates an out of mainline fork of Linux every time he develops something new. Forks are _the_ main mechanism to develop Linux, and it always was. External code is the reality check of mainline code. It is the 'external pool of genes' that is _competing_ against in-tree code. Sometimes the decision to include new bits of code is easy and positive (so it is a fork only very briefly and nobody actually ever has enough time to think of that code as a fork), sometimes it takes some time and the decision is positive, sometimes the decision is immediately negative and the code is rejected, sometimes it's negative after some time. Often code goes through several cycles of rejection before it is merged. The larger the code, the more rejections it will see - and that is natural. Sometimes, very rarely, out of the hundreds of thousands of external changes that went into Linux so far, code seems to be staying 'in limbo' forever - such as the kernel debugger. So _every_ color of the spectrum is present: immediate integration, immediate rejection, long-term integration, long-term rejection, ping-pong of rejections until integration, and even decisions that seem to take a near 'eternity' in very rare cases. If a biologist took a look at these gene pool dynamic parameters alone, without knowing a squat about kernel technology, the likely conclusion would be that this is a healthy, diverse gene pool that is being affected by many many external factors. A true expert at survival, that critter! ;-) For example, i'm at the moment maintaining in excess of 400 patches out of mainline, many of which will never see the daylight of upstream. Many of those are longer-term reality checks that could replace in-tree code in the future or are in the process of replacing in-tree code as we speak. Some are reality checks that _failed_ to replace in-tree code but i'm still maintaining them because i find them useful. If the kernel code that these patches modify happens to be modularized then it is sometimes helpful to my out-of-tree patches (and sometimes it's a pain) - but in any case, i dont require nor suggest upstream maintainers to modularize, just to make my out of tree life easier. Are they still useful to Linux in general? I sure hope so. It was always like this in Linux: modularization is mainly dictated by the needs of the in-tree code - and that's very much on purpose, and always was, to increase the advantages of including good external genes in the kernel gene pool. permission to jump down my throat granted now heh :) Sorry, but i have to disappoint you on that count :-) Nope. I can't equate your soliloquy about the development process with what it appears you are doing in the case of plugsched [...] could you please be a bit more specific - what do you mean under what you are doing in the case of plugsched? In the above section which you characterised as 'soliloquy' (i guess i must have failed to make myself clear enough) i tried to answer the statement you articulated: Place the
Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 17:04 +0200, Ingo Molnar wrote: hi Kasper, * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) I did respond to that one, but perhaps some mail have been getting lost, cause i cant find any more from you in my inbox. CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. I must admit i havent tested the very very latest, will do In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Sure. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: Well, im not sure how good i would be at maintaining SD, my idea was more or less just do the bare minimum to get the thing running on newer kernels :) http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: (sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. (sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. (events/0-9|#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. Actually, now that you mention ogg123, i've had some bugs on CFS with this, i thought it was an ogg123 bug, but now that i remember it its only on CFS i have it.. when i run multiple ogg123 instances, suddenly they will just stop playing and lock up. This happens when someone writes alot fast to me on kopete, where i use ogg123 to play a bling sound.. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] [...] As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL
Re: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the show me the numbers argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > For example, how hard is it for people to just admit that CFS actually > does better than SD on a number of things? Including very much on the > desktop. Actually in benchmarks Ingo has quoted, SD was better on the desktop (by a small margin). CFS is still a bit bursty, though it has significantly improved with age. I know, I did those benchmarks. That being said, I'm really glad to see CFS in your git tree because the new framework around it really improves the readability of the code, and actually makes it easier to start experimenting with scheduler improvements from an entire scheduler like SD to minor bits like priorities. I have one concern - my benchmarking took load average as the common denominator and CFS alters the way the load average is calculated, so perhaps it wasn't a fair comparison. That being said, they still showed CFS could scale very well and SD did not, so considering we're dealing with everything from wristwatches to BlueGene/L I believe the right choice was made. Those arguing for the 2% improvement that SD would give them in their environment would be better off a) helping port SD to the new scheduler framework b) assisting Ingo in improving CFS to meet/exceed their requirements c) giving practical assistance to anyone doing either of the above I'm re-learning git and using my Copious Spare Time (tm) to do what I can - but I have to admit I'm really in over my head. But hey, if Jeff Garzik can do it, so can I. I remember when he couldn't grok C & now he's got control over all our data :-) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 14:48 -0700, Bill Huey wrote: > On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: > > Absolutely. > > > > Con quit for his own reasons. Given that Con himself has said that CFS > > was _not_ why he quite, please discard this... bait. Anyone who's name > > isn't Con Kolivas, who pretends to speak for him is at the very least > > overstepping his bounds, and that is being _very_ generous. > > I know Con personally and I completely identify with his circumstance. This You're still not Con, and I still think it's inappropriate for any person to speak for another unless that person is the designated proxy. > is precisely why he quit the project because of a generally perceived > ignorance and disconnect from end users. Since you side with Ingo on many > issues politically, this response from you is no surprise. Hm. I don't recall entering the world of politics. Where's my cool lapel button? -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: > > He said having reality checks is a good thing. He's encouraging some > poor bastard to maintain plugsched out of mainline to have SD or > whatever to compare to. My bad, it was me who misread that (I didn't react to the name, I was thinking people were talking about maintaining SD that way). Mea culpa. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
> On Mon, 30 Jul 2007, George Sescher wrote: > > > > > > You're advocating plugsched now? On 30/07/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > I'd suggest people here take a look at the code. It's not what Ingo was > saying, and it's not what the code is set up to do. He's just stating that > the way he split up the files, it's actually easier from a patching > standpoint to just create a new file to include instead of > "kernel/sched_fair.c". Ingo's origiinal comment: On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > i'd encourage you to do it - in fact i already tried to prod Peter > Williams into doing exactly that ;) The more reality checks a scheduler > has, the better. He said having reality checks is a good thing. He's encouraging some poor bastard to maintain plugsched out of mainline to have SD or whatever to compare to. I did not say I advocated anything whatsoever. I was asking if this is what Ingo is suggesting people use their energy doing. Not good enough for mainline, but definitely worth keeping around and good enough for... no idea what. I was asking Ingo that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: > > > You're advocating plugsched now? I'd suggest people here take a look at the code. It's not what Ingo was saying, and it's not what the code is set up to do. He's just stating that the way he split up the files, it's actually easier from a patching standpoint to just create a new file to include instead of "kernel/sched_fair.c". But quite frankly, I've seen a lot of totally stupid flamage, and very little actual sense in this discussion. People probably didn't even look at the patches. Did you? For example, how hard is it for people to just admit that CFS actually does better than SD on a number of things? Including very much on the desktop. Ingo posted numbers. Look at those numbers, and then I would suggest some people could seriously consider just shutting up. I've seen too many idiotic people who claim that Con got treated unfairly, without those people admitting that maybe I had a point when I said that we have had a scheduler maintainer for years that actually knows what he's doing. And no, it has never been about "desktop" vs "servers", or similar claptrap. It's been about improving the scheduler. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
> * Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > [...] As far as im concerned, i may be forced to unofficially maintain > > SD for my own systems(allthough lots in the gaming community is bound > > to be interrested, as it does make games lots better) On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > i'd encourage you to do it - in fact i already tried to prod Peter > Williams into doing exactly that ;) The more reality checks a scheduler > has, the better. [ Btw., after the obvious initial merging trouble it > should be much easier to keep SD maintained against future upstream > kernels due to the policy modularity that CFS introduces. (and which > policy-modularity should also help reduce the size and complexity of the > SD patch.) ] You're advocating plugsched now? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: > Absolutely. > > Con quit for his own reasons. Given that Con himself has said that CFS > was _not_ why he quite, please discard this... bait. Anyone who's name > isn't Con Kolivas, who pretends to speak for him is at the very least > overstepping his bounds, and that is being _very_ generous. I know Con personally and I completely identify with his circumstance. This is precisely why he quit the project because of a generally perceived ignorance and disconnect from end users. Since you side with Ingo on many issues politically, this response from you is no surprise. Again, the choices that have been currently made with CFS basically locks him out of development. If you don't understand that, then you don't understand the technical issues he's struggled to pursue. He has a large following which is why this has been a repeated and issue between end users of his tree and a number of current Linux kernel developers. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
* Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > So whats wrong then? > > > > > > Ingo decides to do a better scheduler - to some extent inspired by > > > Con's work. And after 48 hours he publish first version that > > > _anyone_ can see and comment on. Whats wrong with that? > > > > > > Did you expect some lengthy discussion before the coding phase > > > started or what? > > > > > > Just trying to understand what you are arguing about. > > > > If I tried to rewrite a kernel subsystem - should I ever happen to > > dig that deep into kernel matters - while I actually know that > > someone already spent countless hours on exactly rewriting the exact > > same subsystem, I think I would have told that other developer about > > it as soon as I started coding on it. And if it just was a > > > > "Hi Con, > > > > I reconsidered the scheduling ideas again you brought to the Linux > > kernel world. Instead of using your scheduler tough I like to try to > > write a new one with fairness in mind, cause I think this, this and > > this can be improved upon. > > > > I would like to hear your ideas about that as soon as possible and > > would like you to contribute your ideas and also code, where you see > > hit. You can find the git / bazaar / whatever repository where I do > > my developments at: someurl. > > > > Regards, Ingo" > > Sending out the code (and early enough, 48 hours /is/ early enough) > *is* the normal (and good) way to do exactly the communication you > described above, IMHO. yeah. And note that the time from the "ok, this approach might work" point to releasing CFS was even less than the original ~62 hours of CFS development. I dont typically write code because i'm particularly "convinced" about an idea or because i "believe in" an idea, i mostly write code to _check_ whether an idea is worth advancing or not. Writing code is my form of "thinking", and releasing patches is my form of telling others about my "thoughts". I might have guesses about how well something will work out in practice (and i'd certainly be a fool to go out coding blindly), but surprises happen almost always, both in positive and in negative direction, and even with relatively simple patches. CFS started out as an experiment to simplify the scheduler, to clean up the after-effects of a better-desktop-scheduling patch Mike Galbraith sent me. Had anyone told me at that time that i'd end up writing a new scheduler i'd have laughed at the suggestion and i'd have pointed to the large number of pending patches of mine in forms of the -rt tree, the syslet/threadlet code and other stuff that needs fixing a lot more urgent than the task scheduler. During that cleanup work did i realize how a policy-modularized scheduler would allow the bridging of the seemingly unreconcilable friction between the O(1) data structures that things like RT scheduling needs and the binary tree that "fair share scheduling" concepts dictate. (most of the complexity in kernel code like the scheduler derives from complexity in data structures, so you start writing code by thinking about your data structures.) And the time from the point where i thought "ok, this fair-share thing behaves pretty well and it certainly looks simpler than the current code" to the announcement on lkml was more on the order of hours than days - much of the 62 hours were spent on ripping out the old code and on getting the new design up and running. There was simply no code in existence before CFS which has proven the code simplicity/design virtues of 'fair scheduling' - SD was more of an argument _against_ it than for it. I think maybe even Con might have been surprised by that simplicity: in his first lkml reaction to CFS he also wrote that he finds the CFS code "beautiful": http://lkml.org/lkml/2007/4/14/199 and my reply to Con's mail: http://lkml.org/lkml/2007/4/15/64 still addresses a good number of points raised in this thread i think. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 16:31 +0200, Diego Calleja wrote: > El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> > escribió: > > > The scheduler could have and still can undertake good solid transformation, > > but getting folks to listen is another story which is why Con quit. CFS > > basically locks him and his ideas out, not just from a technical stand > > This is just wrong: AFAIK nobody is stopping Con or any other people from > continuing developing SD or any other scheduler, and CFS certainly is subject > to criticism. The idea that Linux can't use other innovative ideas in the > scheduler > is only in your mind. Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 08:23:31PM +0200, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > > I > > > > > actually also think that the communication between Ingo and Con > > > > > could have been better especially when Ingo decided to write CFS > > > > > while Con was still working hard on SD. > > > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > > at about 48 hours after he started to work on CFS? > > > > > > Yes. > > > > So whats wrong then? > > Ingo decides to do a better scheduler - to some extent inspired by > > Con's work. And after 48 hours he publish first version that _anyone_ > > can see and comment on. Whats wrong with that? > > > > Did you expect some lengthy discussion before the coding phase started > > or what? > > > > Just trying to understand what you are arguing about. > > If I tried to rewrite a kernel subsystem - should I ever happen to dig > that deep into kernel matters - while I actually know that someone > already spent countless hours on exactly rewriting the exact same > subsystem, I think I would have told that other developer about it as > soon as I started coding on it. The usual way to communicate such things on lkml are with patches as also happened in this case. It's not like Ingo had secretly developing a scheduler in parallel for weeks or months but. But I assume all the fuzz is about something else - it cannot be about a these 48 hours - I hope.. Enough on this - back to work. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Satyam Sharma: > Hi Martin, Hi Satyam, > > I believe that Ingo did not meant any bad at all. I think its just > > the way he works, he likes to have code before saying anything. But > > still I believe before I'd go about replacing someone else code > > completely I would inform that developer beforehand, even if it then > > turns out not to be feasible at all. No need to anounce it to the > > world already, but I would have informed that developer. > > IMHO, what you're suggesting is: (1) not the way development normally > happens in Linux, and, (2) not the way it /should/ happen, either. If > there's something (subsystem, any code big or small) I think I can do > better or have an idea for, I /should/ be able to just hack on it a bit > and then send it out so everybody can comment on it. Why should I be > forced to dance/discuss around with some other people, when the faster > and more effective way would be just present the code/patch that I > have in my mind as an RFC? Hmmm, that email would have taken how long? 5 minutes maybe? I just feel that I would have written it if I happen to know that another developer spent lots of time and effort into a subsystem I plan to rewrite. Its just human logic to me. Especially when I happen to know that the other developer may be new to the kernel development process as I know it from a internal view point. The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. I always believed that kernel developers are human beings and no robots. And thus the kernel development process IMHO should be designed with human developers in mind instead of robots which take no offence out of anything. Otherwise things like what happened here will happen again and again and again and talent is lost. It is damn good to take technical merits into full account! But ignoring human aspects of development actually will hinder this. Cause then in the end its not about technical merits anymore that do the decision, but that human aspects that have been ignored and are floating around unconsiously. Actually I do believe that this discussion already took more resources than actually writing a few more mails and doing a bit more communication here and there... IMHO the fact that this discussion exists already shows that something in the process of submitting kernel patches and supporting involvement in kernel development can be improved upon. > See, Martin, in the end it's not about developer A vs developer B. It's > about making the kernel the best out there -- that's what the users > want, anyway. Yes, I fully understand (and have said so earlier myself) > that there's a very important "social" aspect to development on such > projects, but it's best if developer B understands that this is the way > things do (and should) happen and adapt to it. [ It's not like I've > been around for long, however, but the above is still my opinion, fwiw. > ] I am not saying that developer B (Con) does not have his share in how it all happened. As written before I got the impression that Con reacted hurt where from my point of view no offence was meant - and I told him that. But from what I know it would have been possible to actually deal with that quite a bit better than has happened. And it would not have taken much effort. Well actually I think it would have been quite easy to take the talent that has offered itself. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi Martin, On Sun, 29 Jul 2007, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > > I > > > > > actually also think that the communication between Ingo and Con > > > > > could have been better especially when Ingo decided to write CFS > > > > > while Con was still working hard on SD. > > > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > > at about 48 hours after he started to work on CFS? > > > > > > Yes. > > > > So whats wrong then? > > Ingo decides to do a better scheduler - to some extent inspired by > > Con's work. And after 48 hours he publish first version that _anyone_ > > can see and comment on. Whats wrong with that? > > > > Did you expect some lengthy discussion before the coding phase started > > or what? > > > > Just trying to understand what you are arguing about. > > If I tried to rewrite a kernel subsystem - should I ever happen to dig > that deep into kernel matters - while I actually know that someone > already spent countless hours on exactly rewriting the exact same > subsystem, I think I would have told that other developer about it as > soon as I started coding on it. And if it just was a > > "Hi Con, > > I reconsidered the scheduling ideas again you brought to the Linux kernel > world. Instead of using your scheduler tough I like to try to write a new > one with fairness in mind, cause I think this, this and this can be > improved upon. > > I would like to hear your ideas about that as soon as possible and would > like you to contribute your ideas and also code, where you see hit. You > can find the git / bazaar / whatever repository where I do my > developments at: someurl. > > Regards, Ingo" Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. > I believe that Ingo did not meant any bad at all. I think its just the way > he works, he likes to have code before saying anything. But still I > believe before I'd go about replacing someone else code completely I > would inform that developer beforehand, even if it then turns out not to > be feasible at all. No need to anounce it to the world already, but I > would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important "social" aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Diego Calleja: > > This time it was Con being the Mindcraft catalyst. But he's on *our* > > side and he got beat down by the Linux kernel community. That's the > > tragedy here. He was beaten down by the very people he was trying to > > help out and support. It should have been handled better. > > Get real: I don't the linux development has always been "friendly". The > idea of a "GNU-hippie community" where everybody is good and helps > others and shares their pots is what the Sun bloggers seem to think > that opensolaris should resemble, but it doesn't matches the real > world. Actually I have seen friendly communities around Linux and free software. Like the KDE project, the ck patchset mailing list community, the TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar community, quite some parts of the Debian community just to name a few. So I know that it can be different. I know that its inaccurate to talk about the whole Linux kernel community. I had quite friendly contacts with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg Kroah-Hartman. So what would be wrong with looking at how this worked out and why and how it would be possible to avoid loosing a talented developer? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > I > > > > actually also think that the communication between Ingo and Con > > > > could have been better especially when Ingo decided to write CFS > > > > while Con was still working hard on SD. > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > at about 48 hours after he started to work on CFS? > > > > Yes. > > So whats wrong then? > Ingo decides to do a better scheduler - to some extent inspired by > Con's work. And after 48 hours he publish first version that _anyone_ > can see and comment on. Whats wrong with that? > > Did you expect some lengthy discussion before the coding phase started > or what? > > Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a "Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo" I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. And aside from that there has been communication before and after this event that IMHO could have been "better". And thats not only targetted at Ingo. A view this whole issue as "everyone who was involved in it, actually was involved in it and has his share in its outcome". So everyone has a great chance to learn something out of it. (That includes me of course, too.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > I > > > actually also think that the communication between Ingo and Con could > > > have been better especially when Ingo decided to write CFS while Con > > > was still working hard on SD. > > > > You realize that Ingo posted his code for anyone to look at/comment at > > about 48 hours after he started to work on CFS? > > Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sonntag, 29. Juli 2007, Kasper Sandberg wrote: > On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote: > > Hi, > > > > I never tried Con's patchset, for two reasons: > > I tried his 2.4 patches ones, and I never saw any improvements. So when > > people were reporting huge improvements with his SD scheduler, I compared > > that with the reports of huge improvements with his 2.4 kernel patches. > > Well thats a reason if there ever were one... > yes, it is. The fans claimed once lots of stuff that was not true for me. So why believing them 'now'? > > ... > > The second: too many patches. I only would have tried one or two, but the > > ck-patchset is a lot bigger.. and I am a little bit uneasy about that. > > so use only the scheduler? nobody forces you to do many things.. but which one is needed? http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.22/2.6.22-ck1/patches/ six patches who start with 'sched-' and which one is needed? and which is not? Can I only use sched-staircase-deadline-cpu-scheduler.patch or do I need the others too? > Better than old vanilla yes, but than SD? well, you should give it a > try. > see above. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
hi Kasper, * Kasper Sandberg <[EMAIL PROTECTED]> wrote: > Im still not so keen about this, Ingo never did get CFS to match SD in > smoothness for 3d applications, where my test subjects are quake(s), > world of warcraft via wine, unreal tournament 2004. And this is > despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: (sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. (sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. (events/0-9|#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] > [...] As far as im concerned, i may be forced to unofficially maintain > SD for my own systems(allthough lots in the gaming community is bound > to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> escribió: > The scheduler could have and still can undertake good solid transformation, > but getting folks to listen is another story which is why Con quit. CFS > basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. > This time it was Con being the Mindcraft catalyst. But he's on *our* side > and he got beat down by the Linux kernel community. That's the tragedy here. > He was beaten down by the very people he was trying to help out and > support. It should have been handled better. Get real: I don't the linux development has always been "friendly". The idea of a "GNU-hippie community" where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > I > > actually also think that the communication between Ingo and Con could > > have been better especially when Ingo decided to write CFS while Con > > was still working hard on SD. > > You realize that Ingo posted his code for anyone to look at/comment at > about 48 hours after he started to work on CFS? Yes. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
> I > actually also think that the communication between Ingo and Con could > have been better especially when Ingo decided to write CFS while Con was > still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > On Sat, 28 Jul 2007, Diego Calleja wrote: > > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > > > So "modal" things are good for fixing behaviour in the short run. > > > But they are a total disaster in the long run, and even in the > > > short run they tend to have problems (simply because there will be > > > cases that straddle the line, and show some of _both_ issues, and > > > now *neither* mode is the right one) > > > > I fully agree with this, but plugsched could have avoided this > > useless "division" on the topic of SD vs CFS. IMO that counts as an > > advantage, too ;) > > Sure. I actually think it's a huge advantage (see the ManagementStyle > file on pissing people off), but at the same time, I don't like playing > politics with technology. The kernel is a technical project, and I make > technical decisions. IMHO thats an illusion. The kernel has become a community project pretty soon after you have released it initially. And the community members are human beings. Thus while the kernel source code in itself for sure describes technical processes, the kernel is more than just a technical project. > So I absolutely detest adding code for "political" reasons. I can understand this and I agree to it, cause it would mean fixing political things on technical grounds and thus not fixing them at all. > I personally feel that modal behaviour is bad, so it would introduce > what is in my opinion bad code, and likely result in problems not being > found and fixed as well (because people would pick the thing that > "works for them", and ignore the problems in the other module). So > while I don't like making irreversible decisions (and the choice of CFS > wasn't irreversible in itself, but if it pisses off Con, _that_ is > generally not reversible), I dislike even more making a half-assed > decision. I agree to this to some extent. But if the mainline kernel does not contain suitable solutions for one subsystem people will tend to plug in other solutions that work for them even where there is no boot or runtime plugability. I have been using TuxOnIce (formerly suspend2) for quite some time and didn't even try the in-kernel-suspend-to-disk stuff since quite some kernel versions since I could not have been bothered anymore after it was failing back then. So when there are two different approaches with good following it may have be good to have some plugability for testing things. But it may be difficult to remove it afterwards again..., but it would still be possible to remove plugins that are only used rarely and they how the other ones evolve. > So rather than making a choice at all, my other choice would have been > to not merge _either_ scheduler, and let people just continue to fight > it out. Would that have made people happier? I seriously doubt it. I tried speaking to Con and Ingo whether they could settle their issue with one another and work together. In *private* mails, away from all the flame throwing. Actually I believe that human things should be resolved on the human side, not on the technical one. And as I perceive no serious attempt has been made on that - except my own maybe. Maybe just writing an email to both Con and Ingo where you told both of them your concerns and thoughts would have helped a lot. A "Hi Con and Ingo, Con, I do not believe that you are able to maintain SD for reason 1,2 and 3. But I do think that Ingo could. But I think, that you wrote great code and brought in good scheduler concepts and ideas to the Linux world. Now Ingo has CFS and you have SD... could there be a way for you to stay involved with scheduler issues and work together with Ingo? If so how could it look like? Ingo, do you see areas where Con can help you with? Are there things in SD that you would like to have in CFS? Do you see a way to work with Con together on the scheduler?" (just a draft;-) for example. It would have given Con some recognition for his work. It could have helped to address the political, well not even the political, but the human issue here. I believe that this is what Con missed the most: Getting some form of recognition from the "official" kernel people! I tried to give some recognition, but I am "just" a user of his patches. Would that have been difficult for you to write, Linus? Its not too late for giving Con some recognition. A simple "Hi Con, I am sorry that you decided to leave kernel development. I felt I had to make a decision about the scheduler thing and these where my concerns... I just wanted to tell you that I did not mean any personal offence with you and did not have any real issue with your code at all, Regards Linus" as an aftermath could still help. Just a little gesture maybe - but it can make a big difference. Maybe without even asking him to come back... I think Con made his decision for now at least.
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole "eat your own dogfood" is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > On Sat, 28 Jul 2007, Jan Engelhardt wrote: > > You cannot please everybody in the scheduler question, that is clear, > > then why not offer dedicated scheduling alternatives (plugsched comes > > to mind) and let them choose what pleases them most, and handles > > their workload best? [...] > So I personally think that it's much better to find a setup that works > "well enough" for people, without having modal behaviour. People > complain and gripe now, but what people seem to be missing is that it's > a journey, not an end-of-the-line destination. We haven't had a single > release kernel with the new scheduler yet, so the only people who have > tried it are either > > (a) interested in schedulers in the first place (which I think is > *not* a good subset, because they have very specific expectations of > what is right and what is wrong, and they come into the whole thing > with that mental baggage) > > (b) people who test -rc1 kernels (I love you guys, but sadly, you're > not nearly as common as I'd like ;) > > so the fact is, we'll find out more information about where CFS falls > down, and where it does well, and we'll be able to *fix* it and tweak > it. I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 had interruptions in music playback initially even though the machine was idling - while at the same time music playback was perfectly fine with SD since quite some iterations. After quite some iterations of testing new CFS versions from Ingo it started working like I think it should. Expecting a interruption free music playback IMO by no way is any mental baggage. I for sure am interested in schedulers, but actually I do not understand the exact principles by with SD and CFS work, I just had no time to look at them closer, and thus just looked at: How does it behave on my laptops with different desktop loads? Actually from a technical point of view I do not care whether CFS or SD goes in, cause I simply understand enough of the technical concepts behind them. And since they are behaving roughly the same on my laptops now I have no issue with CFS going in from a functional view. It seems to do what I expect from a scheduler and I am happy with that. While I have nothing against CFS in the kernel, I actually do not like the way the decision was done and how it was communicated. Its not the outcome of the decision but the way it was done that bothers me. I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. I do think that it would not have been necessary to loose Con's talent. Sure I think that Con had its share in it, but it does not make sense to concentrate on his share, cause only he can do that and he is gone for now. But thats exactly what I perceive you are doing. And I realize it doesn't make sense for me at all to concentrate at your or Ingo's share. I made my point and unless you Ingo and the others involved decide to look at whether there might be something you have done that has contributed to loosing the talent of a good kernel developer the issue can't be helped. Unless people decide to look at themselves instead of pointing out what in their eyes has been wrong with others, the issue will stand still. I am pretty confident that SD in the kernel would have been a viable choice as well and that Con would have done his best to support and maintain it. Well now thats history. Con decided to stay out of kernel development and I actually can understand him. I believe it is possible to learn something out of how this all happened. And actually I merely wanted to point this out to you. Whether you decide to learn something out of it or not, actually is your choice. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > People are suggesting that you'd have a separate "desktop kernel". > That's insane. It also shows total ignorance of maintainership, and > reality. And I bet most of the people there haven't tested _either_ > scheduler, they just like making statements. Ok, hands up again. I tested both schedulers. And I know a lot of people from the ck patchset mailing list did, despite its narrow ck patchset related topic > The fact is, I've _always_ considered the desktop to be the most > important part. And I suspect that that actually is true for most > kernel developers, because quite frankly, that's what 99% of them ends > up using. If a kernel developer uses Windows for his day-to-day work, I > sure as hell wouldn't want to have him developing Linux. That has > nothing to do with anything anti-windows: but the whole "eat your own > dogfood" is a very fundamental thing, and somebody who doesn't do that > shouldn't be allowed to be even _close_ to a compiler! > > So the whole argument about how kernel developers think that the > desktop isn't important is totally made-up crap by Con, and then > parrotted by osnews and other places. Ah, well. So where for example is a working, fast and reliable snapshot solution despite of one being available for *years*? And no, suspend to ram just doesn't cut it - its a complete nonsense for my laptop usage pattern. > And btw, "the desktop" isn't actually one single load. It's in fact a > lot of very different loads, and different people want different > things. What makes the desktop so interesting is in fact that it shows > more varied usage than any other niche - and no, 3D gaming isn't "it". 3D gaming was only *one* workload that people where happy with when running SD. > Con wass fixated on one thing, and one thing only, and wasn't > interested in anythign else - and attacked people who complained. > Compare that to Ingo, who saw that what Con's scheduler did was good, > and tried to solve the problems of people who complained. One thing? How about 1) various improvements to VM stuff and 2) swap prefetch? 3) pluggable schedulers? And various other patch sets. Con concentrated on Desktop performance thats right, but even there he didn't stop. Did you know for example that Con maintained a server related ck patchset for years as well? Where actually is that "Con concrentates only on one thing"? > The ck mailing list is/was also apparently filled with people who all > had the same issues, which is seriously the *wrong* thing to do. Just one question: Did you actually look there *before* making above statement? Can you give a honest answer to this question? > So if you are going to have issues with the scheduler, which one do you > pick: the one where the maintainer has shown that he can maintain > schedulers for years, can can address problems from _different_ areas > of life? Or the one where the maintainer argues against people who > report problems, and is fixated on one single load? Do you have any concrete example? I have only one, one out of countless responses of Con to people how reported problems: The X11 renice issue. If I requested from Ingo to make a scheduler exception that contradicts the design of CFS and I could not convince Ingo that this exception really does make sense, I think I will get into a discussion with Ingo - and exactly that makes perfect sense to me! Actually Ingo did have renicing for X and kernel threads in CFS for quite a while as well. Still that said, I admit that the tone may well have played a role here - as it does in this discussion as well. Maybe Con reacted hurt where no offence was meant at times. But we are all humans, and given all the unfriendlyness Con apparently faced I can understand this. "survival of the fittest maintainer"? Maybe. But I invite you to listen on the last results in biological reasons: Darwins "survival of the fitttest" is only one principle and doesn't explain how lifing beings put themselves together at all. Biologist find out more and more than the genome is no command central at all, but being used by living beings in the way their complex parts being interacting with one another see fit. One should take the tone in this discussion into account. Cause now one can argue that Con doesn't want to maintain the SD scheduler. Well thats true, but once he was more than willing to do that and IMHO he reacted to at least most problem reports in a very professional manner. Maybe not to 100% of them, but can you actually say that from Ingo? From what I seen Ingo also is a human... Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: People are suggesting that you'd have a separate desktop kernel. That's insane. It also shows total ignorance of maintainership, and reality. And I bet most of the people there haven't tested _either_ scheduler, they just like making statements. Ok, hands up again. I tested both schedulers. And I know a lot of people from the ck patchset mailing list did, despite its narrow ck patchset related topic The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole eat your own dogfood is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! So the whole argument about how kernel developers think that the desktop isn't important is totally made-up crap by Con, and then parrotted by osnews and other places. Ah, well. So where for example is a working, fast and reliable snapshot solution despite of one being available for *years*? And no, suspend to ram just doesn't cut it - its a complete nonsense for my laptop usage pattern. And btw, the desktop isn't actually one single load. It's in fact a lot of very different loads, and different people want different things. What makes the desktop so interesting is in fact that it shows more varied usage than any other niche - and no, 3D gaming isn't it. 3D gaming was only *one* workload that people where happy with when running SD. Con wass fixated on one thing, and one thing only, and wasn't interested in anythign else - and attacked people who complained. Compare that to Ingo, who saw that what Con's scheduler did was good, and tried to solve the problems of people who complained. One thing? How about 1) various improvements to VM stuff and 2) swap prefetch? 3) pluggable schedulers? And various other patch sets. Con concentrated on Desktop performance thats right, but even there he didn't stop. Did you know for example that Con maintained a server related ck patchset for years as well? Where actually is that Con concrentates only on one thing? The ck mailing list is/was also apparently filled with people who all had the same issues, which is seriously the *wrong* thing to do. Just one question: Did you actually look there *before* making above statement? Can you give a honest answer to this question? So if you are going to have issues with the scheduler, which one do you pick: the one where the maintainer has shown that he can maintain schedulers for years, can can address problems from _different_ areas of life? Or the one where the maintainer argues against people who report problems, and is fixated on one single load? Do you have any concrete example? I have only one, one out of countless responses of Con to people how reported problems: The X11 renice issue. If I requested from Ingo to make a scheduler exception that contradicts the design of CFS and I could not convince Ingo that this exception really does make sense, I think I will get into a discussion with Ingo - and exactly that makes perfect sense to me! Actually Ingo did have renicing for X and kernel threads in CFS for quite a while as well. Still that said, I admit that the tone may well have played a role here - as it does in this discussion as well. Maybe Con reacted hurt where no offence was meant at times. But we are all humans, and given all the unfriendlyness Con apparently faced I can understand this. survival of the fittest maintainer? Maybe. But I invite you to listen on the last results in biological reasons: Darwins survival of the fitttest is only one principle and doesn't explain how lifing beings put themselves together at all. Biologist find out more and more than the genome is no command central at all, but being used by living beings in the way their complex parts being interacting with one another see fit. One should take the tone in this discussion into account. Cause now one can argue that Con doesn't want to maintain the SD scheduler. Well thats true, but once he was more than willing to do that and IMHO he reacted to at least most problem reports in a very professional manner. Maybe not to 100% of them, but can you actually say that from Ingo? From what I seen Ingo also is a human... Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: On Sat, 28 Jul 2007, Jan Engelhardt wrote: You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? [...] So I personally think that it's much better to find a setup that works well enough for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet, so the only people who have tried it are either (a) interested in schedulers in the first place (which I think is *not* a good subset, because they have very specific expectations of what is right and what is wrong, and they come into the whole thing with that mental baggage) (b) people who test -rc1 kernels (I love you guys, but sadly, you're not nearly as common as I'd like ;) so the fact is, we'll find out more information about where CFS falls down, and where it does well, and we'll be able to *fix* it and tweak it. I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 had interruptions in music playback initially even though the machine was idling - while at the same time music playback was perfectly fine with SD since quite some iterations. After quite some iterations of testing new CFS versions from Ingo it started working like I think it should. Expecting a interruption free music playback IMO by no way is any mental baggage. I for sure am interested in schedulers, but actually I do not understand the exact principles by with SD and CFS work, I just had no time to look at them closer, and thus just looked at: How does it behave on my laptops with different desktop loads? Actually from a technical point of view I do not care whether CFS or SD goes in, cause I simply understand enough of the technical concepts behind them. And since they are behaving roughly the same on my laptops now I have no issue with CFS going in from a functional view. It seems to do what I expect from a scheduler and I am happy with that. While I have nothing against CFS in the kernel, I actually do not like the way the decision was done and how it was communicated. Its not the outcome of the decision but the way it was done that bothers me. I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. I do think that it would not have been necessary to loose Con's talent. Sure I think that Con had its share in it, but it does not make sense to concentrate on his share, cause only he can do that and he is gone for now. But thats exactly what I perceive you are doing. And I realize it doesn't make sense for me at all to concentrate at your or Ingo's share. I made my point and unless you Ingo and the others involved decide to look at whether there might be something you have done that has contributed to loosing the talent of a good kernel developer the issue can't be helped. Unless people decide to look at themselves instead of pointing out what in their eyes has been wrong with others, the issue will stand still. I am pretty confident that SD in the kernel would have been a viable choice as well and that Con would have done his best to support and maintain it. Well now thats history. Con decided to stay out of kernel development and I actually can understand him. I believe it is possible to learn something out of how this all happened. And actually I merely wanted to point this out to you. Whether you decide to learn something out of it or not, actually is your choice. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: On Sat, 28 Jul 2007, Diego Calleja wrote: El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So modal things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) I fully agree with this, but plugsched could have avoided this useless division on the topic of SD vs CFS. IMO that counts as an advantage, too ;) Sure. I actually think it's a huge advantage (see the ManagementStyle file on pissing people off), but at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. IMHO thats an illusion. The kernel has become a community project pretty soon after you have released it initially. And the community members are human beings. Thus while the kernel source code in itself for sure describes technical processes, the kernel is more than just a technical project. So I absolutely detest adding code for political reasons. I can understand this and I agree to it, cause it would mean fixing political things on technical grounds and thus not fixing them at all. I personally feel that modal behaviour is bad, so it would introduce what is in my opinion bad code, and likely result in problems not being found and fixed as well (because people would pick the thing that works for them, and ignore the problems in the other module). So while I don't like making irreversible decisions (and the choice of CFS wasn't irreversible in itself, but if it pisses off Con, _that_ is generally not reversible), I dislike even more making a half-assed decision. I agree to this to some extent. But if the mainline kernel does not contain suitable solutions for one subsystem people will tend to plug in other solutions that work for them even where there is no boot or runtime plugability. I have been using TuxOnIce (formerly suspend2) for quite some time and didn't even try the in-kernel-suspend-to-disk stuff since quite some kernel versions since I could not have been bothered anymore after it was failing back then. So when there are two different approaches with good following it may have be good to have some plugability for testing things. But it may be difficult to remove it afterwards again..., but it would still be possible to remove plugins that are only used rarely and they how the other ones evolve. So rather than making a choice at all, my other choice would have been to not merge _either_ scheduler, and let people just continue to fight it out. Would that have made people happier? I seriously doubt it. I tried speaking to Con and Ingo whether they could settle their issue with one another and work together. In *private* mails, away from all the flame throwing. Actually I believe that human things should be resolved on the human side, not on the technical one. And as I perceive no serious attempt has been made on that - except my own maybe. Maybe just writing an email to both Con and Ingo where you told both of them your concerns and thoughts would have helped a lot. A Hi Con and Ingo, Con, I do not believe that you are able to maintain SD for reason 1,2 and 3. But I do think that Ingo could. But I think, that you wrote great code and brought in good scheduler concepts and ideas to the Linux world. Now Ingo has CFS and you have SD... could there be a way for you to stay involved with scheduler issues and work together with Ingo? If so how could it look like? Ingo, do you see areas where Con can help you with? Are there things in SD that you would like to have in CFS? Do you see a way to work with Con together on the scheduler? (just a draft;-) for example. It would have given Con some recognition for his work. It could have helped to address the political, well not even the political, but the human issue here. I believe that this is what Con missed the most: Getting some form of recognition from the official kernel people! I tried to give some recognition, but I am just a user of his patches. Would that have been difficult for you to write, Linus? Its not too late for giving Con some recognition. A simple Hi Con, I am sorry that you decided to leave kernel development. I felt I had to make a decision about the scheduler thing and these where my concerns... I just wanted to tell you that I did not mean any personal offence with you and did not have any real issue with your code at all, Regards Linus as an aftermath could still help. Just a little gesture maybe - but it can make a big difference. Maybe without even asking him to come back... I think Con made his decision for now at least. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole eat your own dogfood is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: The scheduler could have and still can undertake good solid transformation, but getting folks to listen is another story which is why Con quit. CFS basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sonntag, 29. Juli 2007, Kasper Sandberg wrote: On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote: Hi, I never tried Con's patchset, for two reasons: I tried his 2.4 patches ones, and I never saw any improvements. So when people were reporting huge improvements with his SD scheduler, I compared that with the reports of huge improvements with his 2.4 kernel patches. Well thats a reason if there ever were one... yes, it is. The fans claimed once lots of stuff that was not true for me. So why believing them 'now'? ... The second: too many patches. I only would have tried one or two, but the ck-patchset is a lot bigger.. and I am a little bit uneasy about that. so use only the scheduler? nobody forces you to do many things.. but which one is needed? http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.22/2.6.22-ck1/patches/ six patches who start with 'sched-' and which one is needed? and which is not? Can I only use sched-staircase-deadline-cpu-scheduler.patch or do I need the others too? Better than old vanilla yes, but than SD? well, you should give it a try. see above. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
hi Kasper, * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: (sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. (sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. (events/0-9|#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] [...] As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. And aside from that there has been communication before and after this event that IMHO could have been better. And thats not only targetted at Ingo. A view this whole issue as everyone who was involved in it, actually was involved in it and has his share in its outcome. So everyone has a great chance to learn something out of it. (That includes me of course, too.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Diego Calleja: This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. Actually I have seen friendly communities around Linux and free software. Like the KDE project, the ck patchset mailing list community, the TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar community, quite some parts of the Debian community just to name a few. So I know that it can be different. I know that its inaccurate to talk about the whole Linux kernel community. I had quite friendly contacts with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg Kroah-Hartman. So what would be wrong with looking at how this worked out and why and how it would be possible to avoid loosing a talented developer? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
