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 ...
[ message continues ]

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

-

[ message continues ]

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

-

[ message continues ]

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

-

[ message continues ]

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

-

[ message continues ]

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

[ message continues ]

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

-

[ message continues ]

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

[ message continues ]

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

-

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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
-

[ message continues ]