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 increas
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
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? 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
> 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
> * 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: 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.) ] chuckle 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: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: chuckle 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. snip long other discussion unrelated to my question 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/
