Date:	Wed, 24 Mar 1999 00:18:48 +0300 (IDT)
From:	Gadi Oxman <gadio@netvision.net.il>
To:	Gerard Roudier <groudier@club-internet.fr>
Subject: Re: disk head scheduling

On Tue, 23 Mar 1999, Gerard Roudier wrote:

> > That's why we already have such a function!
> 
> That has been the error. I mean to only have this function, since:
> 
> A) Linux is doing IOs per block or per page from the kernel and we need  
>    to coalesce and sort this small virtual IOs somewhere.
> 
> B) The Linux design is, at the moment, to perform this work from
>    ll_rw_blk.
> 
> The get_queue() only function looks like some band-aid for IDE to me.
> Since too partial design is bad design I am not going to use this method.

Ahem. It's fun to redesign and improve and rewrite code over and over,
and I'm all for it just for the challenge, but we have to remember that
the Linux block layer I/O subsystem definitely doesn't perform bad in
practice, so in my opinion this fact alone proves that it is not a bad
design.

The get_queue() addition was an evolutional rather than a revolutional
enhancements. Let me highlight its advantages:

1.	Completely backward compatible. Device drivers aren't forced
	to use it - it automagically works will all the block drivers,
	and at the time we had many relavant block devices; not just
	SCSI and IDE, all the CDROM block drivers as well.

2.	It does allow us to have several queues per major number. It is
	up to the device driver to choose the number of queues which are
	most appropriate for it, and the number of devices which will
	share a queue.

3.	The queues are shared between the low level device driver and
	the ll_rw_blk.c queueing layer. This means that while a request
	is being serviced by the low level driver, queued requests are
	*still* visible to the higher layers, and new blocks can still
	be merged into existing requests.

	When I added the multiple queues per major to the IDE driver,
	the other approach which I have considered was to use private
	per-drive queues, not shared with ll_rw_blk, and to remove
	queues from the per-major queue into the private per-device
	queue (like the approach used in the SCSI subsystem). This will
	give us part of the advantages, but lacks the advantage of sharing
	outlined above.

So we had an evolutional change which didn't affect existing drivers,
was integrated nicely with the current design, and was used to gain
impressive performance advantages. It wasn't designed to be revolutionary,
and doesn't prevent us from rewriting the Linux block layer anytime we
need a new challenge to work on. Was the addition of it to the kernel a
bad design or band-aid for IDE?

> Regards,
>    Gérard.

Regards,

Gadi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/