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.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
 block/Kconfig.iosched    |   12 ++++----

 block/as-iosched.c       |   32 -----------------------

 block/cfq-iosched.c      |   29 --------------------

 block/deadline-iosched.c |   10 -------

 block/elevator.c         |   54 +--------------------------------------

 block/ll_rw_blk.c        |    8 -----

 block/noop-iosched.c     |   11 -------

 include/linux/elevator.h |   26 ------------------

 kernel/sched.c           |    1

 9 files changed, 8 insertions(+), 175 deletions(-)
424b43bdb56389a6dd2f6bd5c3c6d519ff3ffe2d

diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched

index 7e803fc..c720bee 100644

--- a/block/Kconfig.iosched

+++ b/block/Kconfig.iosched

@@ -13,7 +13,7 @@ config IOSCHED_NOOP

 	  the kernel.
 config IOSCHED_AS

-	tristate "Anticipatory I/O scheduler"

+	bool "Anticipatory I/O scheduler"

 	default y

 	---help---

 	  The anticipatory I/O scheduler is generally a good choice for most

@@ -22,7 +22,7 @@ config IOSCHED_AS

 	  especially some database loads.
 config IOSCHED_DEADLINE

-	tristate "Deadline I/O scheduler"

+	bool "Deadline I/O scheduler"

 	default y

 	---help---

 	  The deadline I/O scheduler is simple and compact, and is often as

@@ -32,7 +32,7 @@ config IOSCHED_DEADLINE

 	  anticipatory I/O scheduler and so is a good choice.
 config IOSCHED_CFQ

-	tristate "CFQ I/O scheduler"

+	bool "CFQ I/O scheduler"

 	default y

 	---help---

 	  The CFQ I/O scheduler tries to distribute bandwidth equally

@@ -48,13 +48,13 @@ choice

 	  block devices.
 	config DEFAULT_AS

-		bool "Anticipatory" if IOSCHED_AS=y

+		bool "Anticipatory" if IOSCHED_AS
 	config DEFAULT_DEADLINE

-		bool "Deadline" if IOSCHED_DEADLINE=y

+		bool "Deadline" if IOSCHED_DEADLINE
 	config DEF...
[ message continues ]

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
-

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
-

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
-

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 
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
-

On Sun, 25 Nov 2007 17:56:54 +0100
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

-

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,
There's always a risk with "duplicate", like several drivers for the

same hardware. I'm not disputing that.
--

Jens Axboe
-

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.

-

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 
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 
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
-

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,
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
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.

-

(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.

--

Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
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.

-

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.
And I'm trying to explain why your personal opinion is wrong in many 
There's nothing forbiding this, it's simply the question what results in 
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 
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
-

Anyway, your later arguments could suggest you've understood,
what I've meant. And maybe abortion isn't bad association here...
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
My congratulations! Of course, removing is something necessary, but I wish
you many problems! (== many users)
Thanks,

Jarek P.

-