make I/O schedulers non-modular
PATCH 1/1 make I/O schedulers non-modular
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.
---
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
block/Kconfig.iosched +6 -6
@@ -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 DEFAULT_CFQ - bool "CFQ" if IOSCHED_CFQ=y + bool "CFQ" if IOSCHED_CFQ config DEFAULT_NOOP bool "No-op"
block/as-iosched.c +0 -32
@@ -149,9 +149,6 @@ enum arq_state {#define RQ_STATE (rq) ((enum arq_state)(rq)->elevator_private2)#define RQ_SET_STATE (rq, state) ((rq)->elevator_private2 = (void *) state) -static DEFINE_PER_CPU(unsigned long, ioc_count); -static struct completion *ioc_gone; -static void as_move_to_dispatch (struct as_data *ad,struct request *rq);static void as_antic_stop (struct as_data *ad);
@@ -163,16 +160,6 @@ static void as_antic_stop(struct as_data *ad);static void free_as_io_context (struct as_io_context *aic) {kfree (aic); -elv_ioc_count_dec (ioc_count); -if (ioc_gone && !elv_ioc_count_read (ioc_count)) -complete (ioc_gone); -} - -static void as_trim (struct io_context *ioc) -{ -if (ioc->aic) -free_as_io_context (ioc->aic); - ioc->aic =NULL ; }/* Called when the task exits */
@@ -200,7 +187,6 @@ static struct as_io_context *alloc_as_io_context(void) ret->seek_total =0 ; ret->seek_samples =0 ; ret->seek_mean =0 ; -elv_ioc_count_inc (ioc_count); }return ret;
@@ -1453,12 +1439,10 @@ static struct elevator_type iosched_as = { .elevator_may_queue_fn = as_may_queue, .elevator_init_fn = as_init_queue, .elevator_exit_fn = as_exit_queue, - .trim = as_trim, }, .elevator_attrs = as_attrs, .elevator_name = "anticipatory", - .elevator_owner = THIS_MODULE, };static int __init as_init (void )
@@ -1466,21 +1450,5 @@ static int __init as_init(void)return elv_register (&iosched_as); } -static void __exit as_exit(void) -{ -DECLARE_COMPLETION_ONSTACK (all_gone); -elv_unregister (&iosched_as); - ioc_gone = &all_gone; -/* ioc_gone's update must be visible before reading ioc_count */ -smp_wmb (); -if (elv_ioc_count_read (ioc_count)) -wait_for_completion (ioc_gone); -synchronize_rcu (); -} -module_init (as_init); -module_exit (as_exit); -MODULE_AUTHOR ("Nick Piggin" ); -MODULE_LICENSE ("GPL" ); -MODULE_DESCRIPTION ("anticipatory IO scheduler" );
block/cfq-iosched.c +0 -29
@@ -43,9 +43,6 @@ static int cfq_slice_idle = HZ / 125;static struct kmem_cache *cfq_pool;static struct kmem_cache *cfq_ioc_pool; -static DEFINE_PER_CPU(unsigned long, ioc_count); -static struct completion *ioc_gone; -#define CFQ_PRIO_LISTS IOPRIO_BE_NR#define cfq_class_idle (cfqq) ((cfqq)->ioprio_class == IOPRIO_CLASS_IDLE)#define cfq_class_rt (cfqq) ((cfqq)->ioprio_class == IOPRIO_CLASS_RT)
@@ -1184,11 +1181,6 @@ static void cfq_free_io_context(struct io_context *ioc)kmem_cache_free (cfq_ioc_pool, __cic); freed++; } - -elv_ioc_count_mod (ioc_count, -freed); - -if (ioc_gone && !elv_ioc_count_read (ioc_count)) -complete (ioc_gone); }static void cfq_exit_cfqq (struct cfq_data *cfqd,struct cfq_queue *cfqq)
@@ -1267,7 +1259,6 @@ cfq_alloc_io_context(struct cfq_data *cfqd, gfp_t gfp_mask)INIT_LIST_HEAD (&cic->queue_list); cic->dtor = cfq_free_io_context; cic->exit = cfq_exit_io_context; -elv_ioc_count_inc (ioc_count); }return cic;
@@ -1483,7 +1474,6 @@ cfq_drop_dead_cic(struct io_context *ioc, struct cfq_io_context *cic)rb_erase (&cic->rb_node, &ioc->cic_root);kmem_cache_free (cfq_ioc_pool, cic); -elv_ioc_count_dec (ioc_count); } static struct cfq_io_context *
@@ -2270,11 +2260,9 @@ static struct elevator_type iosched_cfq = { .elevator_may_queue_fn = cfq_may_queue, .elevator_init_fn = cfq_init_queue, .elevator_exit_fn = cfq_exit_queue, - .trim = cfq_free_io_context, }, .elevator_attrs = cfq_attrs, .elevator_name = "cfq", - .elevator_owner = THIS_MODULE, };static int __init cfq_init (void )
@@ -2299,22 +2287,5 @@ static int __init cfq_init(void)return ret; } -static void __exit cfq_exit(void) -{ -DECLARE_COMPLETION_ONSTACK (all_gone); -elv_unregister (&iosched_cfq); - ioc_gone = &all_gone; -/* ioc_gone's update must be visible before reading ioc_count */ -smp_wmb (); -if (elv_ioc_count_read (ioc_count)) -wait_for_completion (ioc_gone); -synchronize_rcu (); -cfq_slab_kill (); -} -module_init (cfq_init); -module_exit (cfq_exit); -MODULE_AUTHOR ("Jens Axboe" ); -MODULE_LICENSE ("GPL" ); -MODULE_DESCRIPTION ("Completely Fair Queueing IO scheduler" );
block/deadline-iosched.c +0 -10
@@ -462,7 +462,6 @@ static struct elevator_type iosched_deadline = { .elevator_attrs = deadline_attrs, .elevator_name = "deadline", - .elevator_owner = THIS_MODULE, };static int __init deadline_init (void )
@@ -470,14 +469,5 @@ static int __init deadline_init(void)return elv_register (&iosched_deadline); } -static void __exit deadline_exit(void) -{ -elv_unregister (&iosched_deadline); -} -module_init (deadline_init); -module_exit (deadline_exit); -MODULE_AUTHOR ("Jens Axboe" ); -MODULE_LICENSE ("GPL" ); -MODULE_DESCRIPTION ("deadline IO scheduler" );
block/elevator.c +2 -52
142 lines not on this page · raw message
block/ll_rw_blk.c +0 -8
@@ -2264,7 +2264,6 @@ void blk_start_queueing(struct request_queue *q)else __generic_unplug_device (q); } -EXPORT_SYMBOL (blk_start_queueing);/** * blk_requeue_request - put a request back on queue
@@ -3794,13 +3793,10 @@ int kblockd_schedule_work(struct work_struct *work)return queue_work (kblockd_workqueue, work); } -EXPORT_SYMBOL (kblockd_schedule_work); -void kblockd_flush_work (struct work_struct *work) {cancel_work_sync (work); } -EXPORT_SYMBOL (kblockd_flush_work);int __init blk_dev_init (void ) {
@@ -3858,7 +3854,6 @@ void put_io_context(struct io_context *ioc)kmem_cache_free (iocontext_cachep, ioc); } } -EXPORT_SYMBOL (put_io_context);/* Called by the exitting task */ void exit_io_context (void )
@@ -3931,7 +3926,6 @@ struct io_context *get_io_context(gfp_t gfp_flags, int node)atomic_inc (&ret->refcount);return ret; } -EXPORT_SYMBOL (get_io_context);void copy_io_context (struct io_context **pdst,struct io_context **psrc) {
@@ -3945,7 +3939,6 @@ void copy_io_context(struct io_context **pdst, struct io_context **psrc) *pdst = src; } } -EXPORT_SYMBOL (copy_io_context);void swap_io_context (struct io_context **ioc1,struct io_context **ioc2) {
@@ -3954,7 +3947,6 @@ void swap_io_context(struct io_context **ioc1, struct io_context **ioc2) *ioc1 = *ioc2; *ioc2 = temp; } -EXPORT_SYMBOL (swap_io_context);/* * sysfs parts below
block/noop-iosched.c +0 -11
@@ -96,7 +96,6 @@ static struct elevator_type elevator_noop = { .elevator_exit_fn = noop_exit_queue, }, .elevator_name = "noop", - .elevator_owner = THIS_MODULE, };static int __init noop_init (void )
@@ -104,15 +103,5 @@ static int __init noop_init(void)return elv_register (&elevator_noop); } -static void __exit noop_exit(void) -{ -elv_unregister (&elevator_noop); -} -module_init (noop_init); -module_exit (noop_exit); - -MODULE_AUTHOR ("Jens Axboe" ); -MODULE_LICENSE ("GPL" ); -MODULE_DESCRIPTION ("No-op IO scheduler" );
include/linux/elevator.h +0 -26
@@ -55,7 +55,6 @@ struct elevator_opselevator_init_fn *elevator_init_fn;elevator_exit_fn *elevator_exit_fn; -void (*trim)(struct io_context *); };#define ELV_NAME_MAX (16)
@@ -75,7 +74,6 @@ struct elevator_typestruct elevator_ops ops;struct elv_fs_entry *elevator_attrs;char elevator_name[ELV_NAME_MAX ]; -struct module *elevator_owner; };/*
@@ -120,7 +118,6 @@ extern void elv_put_request(struct request_queue *, struct request *);* io scheduler registration */ extern int elv_register (struct elevator_type *); -extern void elv_unregister (struct elevator_type *);/* * io scheduler sysfs switching
@@ -184,28 +181,5 @@ enum {INIT_LIST_HEAD (&(rq)->donelist); \ } while (0) -/* -* io context count accounting - */ -#define elv_ioc_count_mod (name, __val) \ - do { \ - preempt_disable(); \ - __get_cpu_var(name) += (__val); \ - preempt_enable(); \ - } while (0) - -#define elv_ioc_count_inc (name) elv_ioc_count_mod(name, 1) -#define elv_ioc_count_dec (name) elv_ioc_count_mod(name, -1) - -#define elv_ioc_count_read (name) \ -({ \ - unsigned long __val = 0; \ - int __cpu; \ - smp_wmb(); \ - for_each_possible_cpu(__cpu) \ - __val += per_cpu(name, __cpu); \ - __val; \ -}) -#endif /* CONFIG_BLOCK */ #endif
kernel/sched.c +0 -1
@@ -4173,7 +4173,6 @@ int task_nice(const struct task_struct *p) {return TASK_NICE (p); } -EXPORT_SYMBOL_GPL (task_nice);/** * idle_cpu - is a given cpu idle currently?
Quoted 5 lines · Adrian Bunk
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.
Signature · 1 line
Jens Axboe
Quoted 8 lines · Jens Axboe
Quoted 5 lines · Adrian Bunk
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.
Quoted 2 lines
Just because you don't
happen to use it is not a reason to remove it.
s/you/you and all distributions you checked/
Quoted 1 line
Jens Axboe
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 8 lines · Adrian Bunk
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Adrian Bunk
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.
Quoted 8 lines
Quoted 1 line
Big nack, I use it all the time for testing.
OK.
Quoted 2 lines
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.
Signature · 1 line
Jens Axboe
Quoted 13 lines · Jens Axboe
Quoted 12 lines · Adrian Bunk
Quoted 8 lines · Jens Axboe
Quoted 5 lines · Adrian Bunk
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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...
Quoted 1 line
Jens Axboe
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 17 lines · Adrian Bunk
Quoted 16 lines · Jens Axboe
Quoted 15 lines · Adrian Bunk
Quoted 8 lines · Jens Axboe
Quoted 5 lines · Adrian Bunk
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.
Quoted 2 lines
Just because you don't
happen to use it is not a reason to remove it.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 2 lines
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.
Signature · 1 line
Jens Axboe
Quoted 9 lines · Jens Axboe
Quoted 1 line · Adrian Bunk
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.
Quoted 5 lines
Quoted 2 lines
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
(cc's lovingly restored. Please do not do that)
Quoted 16 lines · On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[email protected]> wrote:
Quoted 9 lines · Jens Axboe
Quoted 1 line · Adrian Bunk
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 1 line · Andrew Morton
(cc's lovingly restored. Please do not do that)
Thanks! I'm replying off list.
Quoted 25 lines · On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[email protected]> wrote:
Quoted 17 lines
Quoted 10 lines · Jens Axboe
Quoted 2 lines · Adrian Bunk
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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
Quoted 1 line · Jens Axboe
On Sun, Nov 25 2007, Adrian Bunk wrote:
...
Quoted 3 lines
Quoted 1 line
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.
Quoted 9 lines · Jarek Poplawski
Quoted 1 line · Jens Axboe
On Sun, Nov 25 2007, Adrian Bunk wrote:
...
Quoted 3 lines
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 2 lines
Regards,
Jarek P.
cu
Adrian
Signature · 4 lines
"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 SeedAdrian Bunk wrote, On 11/27/2007 05:47 PM:
Quoted 5 lines · Jarek Poplawski
Quoted 4 lines · Jens Axboe
Quoted 1 line · Adrian Bunk
...
Quoted 1 line
Quoted 1 line
Is there any technical reason why we need 4 different schedulers at all?
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 4 lines
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...
Quoted 9 lines
Quoted 2 lines
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.
Quoted 11 lines · Jarek Poplawski
Adrian Bunk wrote, On 11/27/2007 05:47 PM:
Quoted 9 lines · Jarek Poplawski
Quoted 7 lines · Jens Axboe
Quoted 1 line · Adrian Bunk
...
Quoted 2 lines
Quoted 1 line
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",
Quoted 8 lines
Quoted 4 lines
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...
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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).
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
and, it seems, things are usually far from perfect where this right is not respected.
That's wrong.
Quoted 8 lines
Quoted 3 lines
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...
Quoted 2 lines
Regards,
Jarek P.
cu
Adrian
[1] http://lwn.net/Articles/247582/
Signature · 4 lines
"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 SeedAdrian Bunk wrote, On 11/27/2007 11:53 PM:
Quoted 1 line · Jarek Poplawski
...
Quoted 6 lines
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...
...
Quoted 2 lines
As one of the most active code removers in the kernel [1], I can tell you what actually happens in practice:
...
Quoted 4 lines
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.
Quoted 1 line
My congratulations! Of course, removing is something necessary, but I wish
you many problems! (== many users)
Thanks,
Jarek P.
Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
...
Quoted 1 line
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.
Quoted 7 lines · Jarek Poplawski
Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
...Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 1 line
Jarek P.
cu
Adrian
Signature · 4 lines
"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 SeedJarek Poplawski wrote, On 11/27/2007 11:15 PM:
Quoted 1 line
Adrian Bunk wrote, On 11/27/2007 05:47 PM:
...
Quoted 1 line
Quoted 1 line
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.
Quoted 3 lines · 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