Re: Patch for block write clustering

Gadi Oxman (gadio@netvision.net.il)
Wed, 4 Mar 1998 19:36:14 +0300 (IST)


Rik,

> On Wed, 4 Mar 1998, Gadi Oxman wrote:
>
> > Rik, note that IDE devices are not using a single request queue!
>
> > In general, each major has its own request queue (IDE is using
> > a different major for each interface). In 2.1.x, each IDE drive
> > has its own request queue, even if it shares an interface with
> > another drive.
>
> Does this mean that, IDE too, doesn't use the systemwide
> request queue anymore?
> How are the IDE requests reordered? (disk combing etc).
> Then, who _is_ still using the systemwide request queue,
> and what partition schemes are used on those disks.
>
> Rik.

I think that Linux never used a systemwide request queue. We have a shared
systemwide "free requests" pool, but each major has its own request queue.

All block devices are using the code in drivers/block/ll_rw_blk.c to
sort their request queue. The code supports several queues per major
by the function get_queue(), which accepts a kdev_t and returns a pointer
to the head of the queue. Usually, a single queue is returned for each
major.

The IDE driver is using a queue for each drive, but we can potentially
use more queues; for example, if hda2 is an extended partition which is
expanded to <hda5 hda6> and hda3 is a primary partition which is physically
after hda2, the current sort code will reorder requests to hda3 before
requests to hda5 and hda6, which will be sub-optimal if the partitions
are accessed simultaneously.

In the SCSI case, we currently have a single "SCSI disks" queue which is
visible to ll_rw_blk.c, but the requests do not live there for their entire
lifespan as it is the case for the IDE driver -- the SCSI subsystem is
quickly taking the requests from that queue and re-queueing them to
internal per-host and per-drive queues.

Gadi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu