deadline ALWAYS default for dasd devices(s390) ?

deadline ALWAYS default for dasd devices(s390) ?

[Xose Vazquez Perez]

hi,

why is it FORCED ? bypassing a GLOBAL setting and also the kernel command line !!!

drivers/s390/block/dasd.c

/*
 * Allocate and initialize request queue and default I/O scheduler.
 */
static int dasd_alloc_queue(struct dasd_block *block)
{
	int rc;

	block->request_queue = blk_init_queue(do_dasd_request,
					       &block->request_queue_lock);
	if (block->request_queue == NULL)
		return -ENOMEM;

	block->request_queue->queuedata = block;

	elevator_exit(block->request_queue->elevator);
	block->request_queue->elevator = NULL;
	rc = elevator_init(block->request_queue, "deadline");
	if (rc) {
		blk_cleanup_queue(block->request_queue);
		return rc;
	}
	return 0;
}


-thanks-

-- 
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»

Re: deadline ALWAYS default for dasd devices(s390) ?

[Heiko Carstens]

On Mon, Apr 26, 2010 at 02:34:16PM +0200, Xose Vazquez Perez wrote:
> hi,
> 
> why is it FORCED ? bypassing a GLOBAL setting and also the kernel command line !!!
> 
> drivers/s390/block/dasd.c
> 
> /*
>  * Allocate and initialize request queue and default I/O scheduler.
>  */
> static int dasd_alloc_queue(struct dasd_block *block)
> {
> 	int rc;
> 
> 	block->request_queue = blk_init_queue(do_dasd_request,
> 					       &block->request_queue_lock);
> 	if (block->request_queue == NULL)
> 		return -ENOMEM;
> 
> 	block->request_queue->queuedata = block;
> 
> 	elevator_exit(block->request_queue->elevator);
> 	block->request_queue->elevator = NULL;
> 	rc = elevator_init(block->request_queue, "deadline");
> 	if (rc) {
> 		blk_cleanup_queue(block->request_queue);
> 		return rc;
> 	}
> 	return 0;
> }

Horst, Stefan W. or Stefan H. should be able to answer your question.

Re: deadline ALWAYS default for dasd devices(s390) ?

[Stefan Weinhuber]

Heiko Carstens wrote:
> On Mon, Apr 26, 2010 at 02:34:16PM +0200, Xose Vazquez Perez wrote:
>> hi,
>>
>> why is it FORCED ? bypassing a GLOBAL setting and also the kernel command line !!!
>>
> 
> Horst, Stefan W. or Stefan H. should be able to answer your question.

At the time this change was made we had the problem that the
default scheduler chosen by the distributions resulted in
bad performance for DASD devices.
I don't know what options were considered back then, but
I think that having the device driver set a driver specific default
is better than forcing the whole system to use 'our' scheduler.

I agree that hard coding this choice into the driver is not pretty,
but it is pragmatic. Some generic mechanism for setting driver specific 
defaults would be nicer, but I doubt that many other drivers would 
actually benefit from such an interface.

Re: deadline ALWAYS default for dasd devices(s390) ?

[Michael Tokarev]

05.05.2010 11:52, Stefan Weinhuber wrote:
>> On Mon, Apr 26, 2010 at 02:34:16PM +0200, Xose Vazquez Perez wrote:
>>> hi,
>>>
>>> why is it FORCED ? bypassing a GLOBAL setting and also the kernel
>>> command line !!!
>
> At the time this change was made we had the problem that the
> default scheduler chosen by the distributions resulted in
> bad performance for DASD devices.
> I don't know what options were considered back then, but
> I think that having the device driver set a driver specific default
> is better than forcing the whole system to use 'our' scheduler.
>
> I agree that hard coding this choice into the driver is not pretty,
> but it is pragmatic. Some generic mechanism for setting driver specific
> defaults would be nicer, but I doubt that many other drivers would
> actually benefit from such an interface.

See also another thread started just two days ago:

  http://lkml.org/lkml/2010/5/3/404

Just... one more data point... ;)

/mjt

Re: deadline ALWAYS default for dasd devices(s390) ?

[Xose Vazquez Perez]

On 05/05/2010 09:52 AM, Stefan Weinhuber wrote:

hi,

> At the time this change was made we had the problem that the
> default scheduler chosen by the distributions resulted in
> bad performance for DASD devices.

Have you done recently new cfq vs. deadline tests, in z/VM
and LPAR ?

> I agree that hard coding this choice into the driver is not pretty,
> but it is pragmatic. 

It's awful. Easier and simpler from user space: /sys/block/dasdX/queue/scheduler

> Some generic mechanism for setting driver specific
> defaults would be nicer, but I doubt that many other drivers would
> actually benefit from such an interface.

see s390-tools-1.8.4/etc/udev/rules.d/60-readahead.rules
That's the way to do it.

-thanks-

-- 
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»

Re: deadline ALWAYS default for dasd devices(s390) ?

[Rob van der Heij]

On Thu, May 6, 2010 at 9:34 AM, Xose Vazquez Perez
<xose.vazquez@gmail.com> wrote:
> On 05/05/2010 09:52 AM, Stefan Weinhuber wrote:
>
> hi,
>
>> At the time this change was made we had the problem that the
>> default scheduler chosen by the distributions resulted in
>> bad performance for DASD devices.
>
> Have you done recently new cfq vs. deadline tests, in z/VM
> and LPAR ?
>
>> I agree that hard coding this choice into the driver is not pretty,
>> but it is pragmatic.
>
> It's awful. Easier and simpler from user space: /sys/block/dasdX/queue/scheduler
>
>> Some generic mechanism for setting driver specific
>> defaults would be nicer, but I doubt that many other drivers would
>> actually benefit from such an interface.
>
> see s390-tools-1.8.4/etc/udev/rules.d/60-readahead.rules
> That's the way to do it.

</lurk>
Hear, hear!

When it's hardcoded, the performance recommendations become a
self-fulfilling prophecy since it prevents simple souls like myself
from experimenting and show under what circumstances the alternative
is more effective. It would not be the first time. I  still recall the
critsit when some feature of the dasd driver did great in the lab and
failed miserably in real life.
I'm even willing to try wrap my brains around udev if I have to ;-)
<lurk>

Rob