Re: [2.6 patch] make I/O schedulers non-modular
Jarek Poplawski wrote, On 11/27/2007 11:15 PM: > Adrian Bunk wrote, On 11/27/2007 05:47 PM: ... >> There is nothing like a "right of choice". (very late) PS: ...I was a bit confused with this, wondering: so, we've envied you (the West) this "thing" for so many years, and now it seems, you have no idea what's this all about?! Happily it was only my English: http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less "Freedom of choice" was the right term! Regards, Jarek P. PPS: But, of course, no need to discuss this more... unless we're interested in the next Nobel Prize. -- 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: [2.6 patch] make I/O schedulers non-modular
Jarek Poplawski wrote, On 11/27/2007 11:15 PM: Adrian Bunk wrote, On 11/27/2007 05:47 PM: ... There is nothing like a right of choice. (very late) PS: ...I was a bit confused with this, wondering: so, we've envied you (the West) this thing for so many years, and now it seems, you have no idea what's this all about?! Happily it was only my English: http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less Freedom of choice was the right term! Regards, Jarek P. PPS: But, of course, no need to discuss this more... unless we're interested in the next Nobel Prize. -- 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: [2.6 patch] make I/O schedulers non-modular
Adrian Bunk wrote, On 11/27/2007 11:53 PM: > On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote: ... > Most Google hits are about abortion. > > The fact that people use this term in some completely different > context does not give it the meaning you implied it had. > > Oh, and this right of choice also does not exist in Poland... Anyway, your later arguments could suggest you've understood, what I've meant. And maybe abortion isn't bad association here... ... > As one of the most active code removers in the kernel [1], I can tell > you what actually happens in practice: ... > It's always surprising how many people complain when you deprecate or > remove a choice B that choice A wouldn't work for them, and who had > never reported their problems before since choice B worked for them... Of course, all these choices should be reasonably limited, so the opinions of users and maintainers should be always considered. But, I was rather against something else: removing some maybe not very popular, but still not buggy options, only to save a few kilobytes or maintainers' time. > [1] http://lwn.net/Articles/247582/ My congratulations! Of course, removing is something necessary, but I wish you many problems! (== many users) Thanks, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On Wed, Nov 28, 2007 at 12:02:08AM +0100, Jarek Poplawski wrote: > Jarek Poplawski wrote, On 11/27/2007 11:15 PM: > ... > > > Otherwise it's not so hard to overlook some stagnation. > > Btw., after this 'forking' thing etc. it seems I might have lost the point > a little: which removed choices should justify such a fork. Let me try to rephrase it: If you think an open source project does something wrong you have the right to fork it and offer an (in your opinion) better version. This is the right you have. But if you think open source gives you any legal or moral right to demand any featurs or choices or whatever from developers you are completely mistaken. > But, I hope, > you didn't mean your patch only, because then e.g. this stagnation threat > looks like a bit exaggerated... The question how many I/O schedulers we need is anyway in no direction related to my patch. > Jarek P. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
Jarek Poplawski wrote, On 11/27/2007 11:15 PM: ... > Otherwise it's not so hard to overlook some stagnation. Btw., after this 'forking' thing etc. it seems I might have lost the point a little: which removed choices should justify such a fork. But, I hope, you didn't mean your patch only, because then e.g. this stagnation threat looks like a bit exaggerated... Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote: > Adrian Bunk wrote, On 11/27/2007 05:47 PM: > > > On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: > >> On 25-11-2007 18:22, Jens Axboe wrote: > >>> On Sun, Nov 25 2007, Adrian Bunk wrote: > >> ... > Is there any technical reason why we need 4 different schedulers at all? > >>> Until we have the perfect scheduler :-) > >> IMHO this is not enough yet. There is something called "the right > >> of choice", > > > > That's a common misconception about open source software: > > > > There is nothing like a "right of choice". > > There is a "right to change the source code". > > Maybe you are right, maybe I've used wrong words... But, e.g., google > pretends to know about this first right too. And I've meant generally, > not about open software. Most Google hits are about abortion. The fact that people use this term in some completely different context does not give it the meaning you implied it had. Oh, and this right of choice also does not exist in Poland... > > This means you cannot demand from anyone to offer any choices, but you > > can fork the code yourself and use and distribute modified code > > containing any choices you consider reasonable. > > I don't demand anything. I've only expressed my personal opinion > that usually (if possible) the choice is better than no choice. And I'm trying to explain why your personal opinion is wrong in many cases. > And, since I don't know anything in open source forbiding this, I > can ask, why you demand to take away offered choices; actually, I > think it would be much easier if you could fork the other way... There's nothing forbiding this, it's simply the question what results in a better kernel (see below). > >> and, it seems, things are usually far from perfect > >> where this right is not respected. > > > > That's wrong. > > > > It's actually often much worse to have different choices with different > > features and bugfixes than having one version that contains all features > > and all bugfixes. > > It's only a part of the theory: usually it's easier to find some bugs > if there is a possibility to compare a performance with other options; > there is also kind of stimulation and flow of new ideas between them. > Otherwise it's not so hard to overlook some stagnation. Let's leave the theory. As one of the most active code removers in the kernel [1], I can tell you what actually happens in practice: Given: - two choices A and B - user tried choice A and it has a problem (e.g. doesn't work or has bad performance) What happens: - if choice B works, user uses choice B What happens without choice B: - user reports the problem and choice A gets fixed It's always surprising how many people complain when you deprecate or remove a choice B that choice A wouldn't work for them, and who had never reported their problems before since choice B worked for them... > Regards, > Jarek P. cu Adrian [1] http://lwn.net/Articles/247582/ -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
Adrian Bunk wrote, On 11/27/2007 05:47 PM: > On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: >> On 25-11-2007 18:22, Jens Axboe wrote: >>> On Sun, Nov 25 2007, Adrian Bunk wrote: >> ... Is there any technical reason why we need 4 different schedulers at all? >>> Until we have the perfect scheduler :-) >> IMHO this is not enough yet. There is something called "the right >> of choice", > > That's a common misconception about open source software: > > There is nothing like a "right of choice". > There is a "right to change the source code". Maybe you are right, maybe I've used wrong words... But, e.g., google pretends to know about this first right too. And I've meant generally, not about open software. > > This means you cannot demand from anyone to offer any choices, but you > can fork the code yourself and use and distribute modified code > containing any choices you consider reasonable. I don't demand anything. I've only expressed my personal opinion that usually (if possible) the choice is better than no choice. And, since I don't know anything in open source forbiding this, I can ask, why you demand to take away offered choices; actually, I think it would be much easier if you could fork the other way... >> and, it seems, things are usually far from perfect >> where this right is not respected. > > That's wrong. > > It's actually often much worse to have different choices with different > features and bugfixes than having one version that contains all features > and all bugfixes. > It's only a part of the theory: usually it's easier to find some bugs if there is a possibility to compare a performance with other options; there is also kind of stimulation and flow of new ideas between them. Otherwise it's not so hard to overlook some stagnation. Regards, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: > On 25-11-2007 18:22, Jens Axboe wrote: > > On Sun, Nov 25 2007, Adrian Bunk wrote: > ... > >> Is there any technical reason why we need 4 different schedulers at all? > > > > Until we have the perfect scheduler :-) > > IMHO this is not enough yet. There is something called "the right > of choice", That's a common misconception about open source software: There is nothing like a "right of choice". There is a "right to change the source code". This means you cannot demand from anyone to offer any choices, but you can fork the code yourself and use and distribute modified code containing any choices you consider reasonable. > and, it seems, things are usually far from perfect > where this right is not respected. That's wrong. It's actually often much worse to have different choices with different features and bugfixes than having one version that contains all features and all bugfixes. > Regards, > Jarek P. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: On 25-11-2007 18:22, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: ... Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) IMHO this is not enough yet. There is something called the right of choice, That's a common misconception about open source software: There is nothing like a right of choice. There is a right to change the source code. This means you cannot demand from anyone to offer any choices, but you can fork the code yourself and use and distribute modified code containing any choices you consider reasonable. and, it seems, things are usually far from perfect where this right is not respected. That's wrong. It's actually often much worse to have different choices with different features and bugfixes than having one version that contains all features and all bugfixes. Regards, Jarek P. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
Adrian Bunk wrote, On 11/27/2007 05:47 PM: On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: On 25-11-2007 18:22, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: ... Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) IMHO this is not enough yet. There is something called the right of choice, That's a common misconception about open source software: There is nothing like a right of choice. There is a right to change the source code. Maybe you are right, maybe I've used wrong words... But, e.g., google pretends to know about this first right too. And I've meant generally, not about open software. This means you cannot demand from anyone to offer any choices, but you can fork the code yourself and use and distribute modified code containing any choices you consider reasonable. I don't demand anything. I've only expressed my personal opinion that usually (if possible) the choice is better than no choice. And, since I don't know anything in open source forbiding this, I can ask, why you demand to take away offered choices; actually, I think it would be much easier if you could fork the other way... and, it seems, things are usually far from perfect where this right is not respected. That's wrong. It's actually often much worse to have different choices with different features and bugfixes than having one version that contains all features and all bugfixes. It's only a part of the theory: usually it's easier to find some bugs if there is a possibility to compare a performance with other options; there is also kind of stimulation and flow of new ideas between them. Otherwise it's not so hard to overlook some stagnation. Regards, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote: Adrian Bunk wrote, On 11/27/2007 05:47 PM: On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote: On 25-11-2007 18:22, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: ... Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) IMHO this is not enough yet. There is something called the right of choice, That's a common misconception about open source software: There is nothing like a right of choice. There is a right to change the source code. Maybe you are right, maybe I've used wrong words... But, e.g., google pretends to know about this first right too. And I've meant generally, not about open software. Most Google hits are about abortion. The fact that people use this term in some completely different context does not give it the meaning you implied it had. Oh, and this right of choice also does not exist in Poland... This means you cannot demand from anyone to offer any choices, but you can fork the code yourself and use and distribute modified code containing any choices you consider reasonable. I don't demand anything. I've only expressed my personal opinion that usually (if possible) the choice is better than no choice. And I'm trying to explain why your personal opinion is wrong in many cases. And, since I don't know anything in open source forbiding this, I can ask, why you demand to take away offered choices; actually, I think it would be much easier if you could fork the other way... There's nothing forbiding this, it's simply the question what results in a better kernel (see below). and, it seems, things are usually far from perfect where this right is not respected. That's wrong. It's actually often much worse to have different choices with different features and bugfixes than having one version that contains all features and all bugfixes. It's only a part of the theory: usually it's easier to find some bugs if there is a possibility to compare a performance with other options; there is also kind of stimulation and flow of new ideas between them. Otherwise it's not so hard to overlook some stagnation. Let's leave the theory. As one of the most active code removers in the kernel [1], I can tell you what actually happens in practice: Given: - two choices A and B - user tried choice A and it has a problem (e.g. doesn't work or has bad performance) What happens: - if choice B works, user uses choice B What happens without choice B: - user reports the problem and choice A gets fixed It's always surprising how many people complain when you deprecate or remove a choice B that choice A wouldn't work for them, and who had never reported their problems before since choice B worked for them... Regards, Jarek P. cu Adrian [1] http://lwn.net/Articles/247582/ -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
Jarek Poplawski wrote, On 11/27/2007 11:15 PM: ... Otherwise it's not so hard to overlook some stagnation. Btw., after this 'forking' thing etc. it seems I might have lost the point a little: which removed choices should justify such a fork. But, I hope, you didn't mean your patch only, because then e.g. this stagnation threat looks like a bit exaggerated... Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On Wed, Nov 28, 2007 at 12:02:08AM +0100, Jarek Poplawski wrote: Jarek Poplawski wrote, On 11/27/2007 11:15 PM: ... Otherwise it's not so hard to overlook some stagnation. Btw., after this 'forking' thing etc. it seems I might have lost the point a little: which removed choices should justify such a fork. Let me try to rephrase it: If you think an open source project does something wrong you have the right to fork it and offer an (in your opinion) better version. This is the right you have. But if you think open source gives you any legal or moral right to demand any featurs or choices or whatever from developers you are completely mistaken. But, I hope, you didn't mean your patch only, because then e.g. this stagnation threat looks like a bit exaggerated... The question how many I/O schedulers we need is anyway in no direction related to my patch. Jarek P. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
Adrian Bunk wrote, On 11/27/2007 11:53 PM: On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote: ... Most Google hits are about abortion. The fact that people use this term in some completely different context does not give it the meaning you implied it had. Oh, and this right of choice also does not exist in Poland... Anyway, your later arguments could suggest you've understood, what I've meant. And maybe abortion isn't bad association here... ... As one of the most active code removers in the kernel [1], I can tell you what actually happens in practice: ... It's always surprising how many people complain when you deprecate or remove a choice B that choice A wouldn't work for them, and who had never reported their problems before since choice B worked for them... Of course, all these choices should be reasonably limited, so the opinions of users and maintainers should be always considered. But, I was rather against something else: removing some maybe not very popular, but still not buggy options, only to save a few kilobytes or maintainers' time. [1] http://lwn.net/Articles/247582/ My congratulations! Of course, removing is something necessary, but I wish you many problems! (== many users) Thanks, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On 25-11-2007 18:22, Jens Axboe wrote: > On Sun, Nov 25 2007, Adrian Bunk wrote: ... >> Is there any technical reason why we need 4 different schedulers at all? > > Until we have the perfect scheduler :-) IMHO this is not enough yet. There is something called "the right of choice", and, it seems, things are usually far from perfect where this right is not respected. Regards, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
On 25-11-2007 18:22, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: ... Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) IMHO this is not enough yet. There is something called the right of choice, and, it seems, things are usually far from perfect where this right is not respected. Regards, Jarek P. - 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: [2.6 patch] make I/O schedulers non-modular
Andrew Morton wrote: > (cc's lovingly restored. Please do not do that) Thanks! I'm replying off list. > On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > > Jens Axboe wrote: > > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > > Is there any technical reason why we need 4 different schedulers at > > > > all? > > > > > > Until we have the perfect scheduler :-) > > > > > > With some hard work and testing, we should be able to get rid of 'as'. > > > It still beats cfq for some of the workloads that deadline is good at, > > > so not quite yet. > > > > > > > I have the gut feeling that the usual thing happens and people e.g. > > > > not report some cfq problems because as works for them... > > > > > > There's always a risk with "duplicate", like several drivers for the > > > same hardware. I'm not disputing that. > > > > Actually, both 'cfq' and 'as' are broken, and have been repeatedly > > reported as such. Deadline is the only one that currently looks sane, > > and seems like a good starting point for a more involved iosched. But > > keep in mind, the fact that 'cfq' and 'as' are broken may also point to > > a lower-level block-io problem. So, incrementally improving deadline > > may help discovering the problems both 'cfq' and 'as' are plagued with. > > Sorry, but these are vague and unuseful assertions. > > Please send bug reports, preferably with testcases which developers can > use when fixing the bugs. http://bugzilla.kernel.org/show_bug.cgi?id=5900 Thanks again! -- Al - 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: [2.6 patch] make I/O schedulers non-modular
(cc's lovingly restored. Please do not do that) On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > Jens Axboe wrote: > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > Is there any technical reason why we need 4 different schedulers at all? > > > > Until we have the perfect scheduler :-) > > > > With some hard work and testing, we should be able to get rid of 'as'. > > It still beats cfq for some of the workloads that deadline is good at, > > so not quite yet. > > > > > I have the gut feeling that the usual thing happens and people e.g. not > > > report some cfq problems because as works for them... > > > > There's always a risk with "duplicate", like several drivers for the > > same hardware. I'm not disputing that. > > Actually, both 'cfq' and 'as' are broken, and have been repeatedly reported > as such. Deadline is the only one that currently looks sane, and seems like > a good starting point for a more involved iosched. But keep in mind, the > fact that 'cfq' and 'as' are broken may also point to a lower-level block-io > problem. So, incrementally improving deadline may help discovering the > problems both 'cfq' and 'as' are plagued with. > Sorry, but these are vague and unuseful assertions. Please send bug reports, preferably with testcases which developers can use when fixing the bugs. - 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: [2.6 patch] make I/O schedulers non-modular
Jens Axboe wrote: > On Sun, Nov 25 2007, Adrian Bunk wrote: > > Is there any technical reason why we need 4 different schedulers at all? > > Until we have the perfect scheduler :-) > > With some hard work and testing, we should be able to get rid of 'as'. > It still beats cfq for some of the workloads that deadline is good at, > so not quite yet. > > > I have the gut feeling that the usual thing happens and people e.g. not > > report some cfq problems because as works for them... > > There's always a risk with "duplicate", like several drivers for the > same hardware. I'm not disputing that. Actually, both 'cfq' and 'as' are broken, and have been repeatedly reported as such. Deadline is the only one that currently looks sane, and seems like a good starting point for a more involved iosched. But keep in mind, the fact that 'cfq' and 'as' are broken may also point to a lower-level block-io problem. So, incrementally improving deadline may help discovering the problems both 'cfq' and 'as' are plagued with. Thanks! -- Al - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, 25 Nov 2007 17:56:54 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > Is there any technical reason why we need 4 different schedulers at > all? > there is at least one technical reason to need more than one: certain types of storage (both big EMC boxes as well as solid state disks) don't behave like disks and have no seek penalty; any cpu time spent on avoiding seeks is wasted on those, so for these devices one really wants to use a different IO scheduler, one which is much lighter weight - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: > On Sun, Nov 25, 2007 at 05:45:32PM +0100, Jens Axboe wrote: > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: > > > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > > > There isn't any big advantage and doesn't seem to be much usage of > > > > > modular schedulers. > > > > > > > > > > OTOH, the overhead made the kernel image of an x86 defconfig (that > > > > > doesn't use modular schedulers) bigger by nearly 2 kB. > > > > > > > > Big nack, I use it all the time for testing. > > > > > > OK. > > > > > > > Just because you don't > > > > happen to use it is not a reason to remove it. > > > > > > s/you/you and all distributions you checked/ > > > > Well they should make them modules (two of them, that is). > >... > > Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) With some hard work and testing, we should be able to get rid of 'as'. It still beats cfq for some of the workloads that deadline is good at, so not quite yet. > I have the gut feeling that the usual thing happens and people e.g. not > report some cfq problems because as works for them... There's always a risk with "duplicate", like several drivers for the same hardware. I'm not disputing that. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25, 2007 at 05:45:32PM +0100, Jens Axboe wrote: > On Sun, Nov 25 2007, Adrian Bunk wrote: > > On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: > > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > > There isn't any big advantage and doesn't seem to be much usage of > > > > modular schedulers. > > > > > > > > OTOH, the overhead made the kernel image of an x86 defconfig (that > > > > doesn't use modular schedulers) bigger by nearly 2 kB. > > > > > > Big nack, I use it all the time for testing. > > > > OK. > > > > > Just because you don't > > > happen to use it is not a reason to remove it. > > > > s/you/you and all distributions you checked/ > > Well they should make them modules (two of them, that is). >... Is there any technical reason why we need 4 different schedulers at all? I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... > Jens Axboe cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: > On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: > > On Sun, Nov 25 2007, Adrian Bunk wrote: > > > There isn't any big advantage and doesn't seem to be much usage of > > > modular schedulers. > > > > > > OTOH, the overhead made the kernel image of an x86 defconfig (that > > > doesn't use modular schedulers) bigger by nearly 2 kB. > > > > Big nack, I use it all the time for testing. > > OK. > > > Just because you don't > > happen to use it is not a reason to remove it. > > s/you/you and all distributions you checked/ Well they should make them modules (two of them, that is). It's been a long time since I considered a distro .config a benchmark/guideline of any sort. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: > On Sun, Nov 25 2007, Adrian Bunk wrote: > > There isn't any big advantage and doesn't seem to be much usage of > > modular schedulers. > > > > OTOH, the overhead made the kernel image of an x86 defconfig (that > > doesn't use modular schedulers) bigger by nearly 2 kB. > > Big nack, I use it all the time for testing. OK. > Just because you don't > happen to use it is not a reason to remove it. s/you/you and all distributions you checked/ > Jens Axboe cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: > There isn't any big advantage and doesn't seem to be much usage of > modular schedulers. > > OTOH, the overhead made the kernel image of an x86 defconfig (that > doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. Just because you don't happen to use it is not a reason to remove it. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: There isn't any big advantage and doesn't seem to be much usage of modular schedulers. OTOH, the overhead made the kernel image of an x86 defconfig (that doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. Just because you don't happen to use it is not a reason to remove it. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: There isn't any big advantage and doesn't seem to be much usage of modular schedulers. OTOH, the overhead made the kernel image of an x86 defconfig (that doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. OK. Just because you don't happen to use it is not a reason to remove it. s/you/you and all distributions you checked/ Jens Axboe cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: There isn't any big advantage and doesn't seem to be much usage of modular schedulers. OTOH, the overhead made the kernel image of an x86 defconfig (that doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. OK. Just because you don't happen to use it is not a reason to remove it. s/you/you and all distributions you checked/ Well they should make them modules (two of them, that is). It's been a long time since I considered a distro .config a benchmark/guideline of any sort. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25, 2007 at 05:45:32PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: There isn't any big advantage and doesn't seem to be much usage of modular schedulers. OTOH, the overhead made the kernel image of an x86 defconfig (that doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. OK. Just because you don't happen to use it is not a reason to remove it. s/you/you and all distributions you checked/ Well they should make them modules (two of them, that is). ... Is there any technical reason why we need 4 different schedulers at all? I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... Jens Axboe cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, Nov 25 2007, Adrian Bunk wrote: On Sun, Nov 25, 2007 at 05:45:32PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: There isn't any big advantage and doesn't seem to be much usage of modular schedulers. OTOH, the overhead made the kernel image of an x86 defconfig (that doesn't use modular schedulers) bigger by nearly 2 kB. Big nack, I use it all the time for testing. OK. Just because you don't happen to use it is not a reason to remove it. s/you/you and all distributions you checked/ Well they should make them modules (two of them, that is). ... Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) With some hard work and testing, we should be able to get rid of 'as'. It still beats cfq for some of the workloads that deadline is good at, so not quite yet. I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... There's always a risk with duplicate, like several drivers for the same hardware. I'm not disputing that. -- Jens Axboe - 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: [2.6 patch] make I/O schedulers non-modular
On Sun, 25 Nov 2007 17:56:54 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: Is there any technical reason why we need 4 different schedulers at all? there is at least one technical reason to need more than one: certain types of storage (both big EMC boxes as well as solid state disks) don't behave like disks and have no seek penalty; any cpu time spent on avoiding seeks is wasted on those, so for these devices one really wants to use a different IO scheduler, one which is much lighter weight - 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: [2.6 patch] make I/O schedulers non-modular
Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) With some hard work and testing, we should be able to get rid of 'as'. It still beats cfq for some of the workloads that deadline is good at, so not quite yet. I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... There's always a risk with duplicate, like several drivers for the same hardware. I'm not disputing that. Actually, both 'cfq' and 'as' are broken, and have been repeatedly reported as such. Deadline is the only one that currently looks sane, and seems like a good starting point for a more involved iosched. But keep in mind, the fact that 'cfq' and 'as' are broken may also point to a lower-level block-io problem. So, incrementally improving deadline may help discovering the problems both 'cfq' and 'as' are plagued with. Thanks! -- Al - 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: [2.6 patch] make I/O schedulers non-modular
(cc's lovingly restored. Please do not do that) On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) With some hard work and testing, we should be able to get rid of 'as'. It still beats cfq for some of the workloads that deadline is good at, so not quite yet. I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... There's always a risk with duplicate, like several drivers for the same hardware. I'm not disputing that. Actually, both 'cfq' and 'as' are broken, and have been repeatedly reported as such. Deadline is the only one that currently looks sane, and seems like a good starting point for a more involved iosched. But keep in mind, the fact that 'cfq' and 'as' are broken may also point to a lower-level block-io problem. So, incrementally improving deadline may help discovering the problems both 'cfq' and 'as' are plagued with. Sorry, but these are vague and unuseful assertions. Please send bug reports, preferably with testcases which developers can use when fixing the bugs. - 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: [2.6 patch] make I/O schedulers non-modular
Andrew Morton wrote: (cc's lovingly restored. Please do not do that) Thanks! I'm replying off list. On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Sun, Nov 25 2007, Adrian Bunk wrote: Is there any technical reason why we need 4 different schedulers at all? Until we have the perfect scheduler :-) With some hard work and testing, we should be able to get rid of 'as'. It still beats cfq for some of the workloads that deadline is good at, so not quite yet. I have the gut feeling that the usual thing happens and people e.g. not report some cfq problems because as works for them... There's always a risk with duplicate, like several drivers for the same hardware. I'm not disputing that. Actually, both 'cfq' and 'as' are broken, and have been repeatedly reported as such. Deadline is the only one that currently looks sane, and seems like a good starting point for a more involved iosched. But keep in mind, the fact that 'cfq' and 'as' are broken may also point to a lower-level block-io problem. So, incrementally improving deadline may help discovering the problems both 'cfq' and 'as' are plagued with. Sorry, but these are vague and unuseful assertions. Please send bug reports, preferably with testcases which developers can use when fixing the bugs. http://bugzilla.kernel.org/show_bug.cgi?id=5900 Thanks again! -- Al - 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/
