Linux-kernel mailing list archive 2000-04,: Re: ide-scsi problems with multiple CD-Rs on same channel (2.2.14)

# Re: ide-scsi problems with multiple CD-Rs on same channel (2.2.14)

Gadi Oxman (gadio@netvision.net.il)
Thu, 27 Jan 2000 20:35:47 +0200 (IST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Richard A Nelson: "Re: problem with linux 2.2.15pre4 + Rik's VM fix"
- Previous message: Stephen C. Tweedie: "Re: 2.2.1{3,4,5pre*} VM bug found"

Hi,

> Gadi,
>
> Do you what this added?

This patches play with our "drive scheduling" decisions when several
drives are serialized by the same hwgroup.

In 2.0.x, we used to put requests for both drives on the interface in
the same queue, and finish all requests for one drive before switching
to the other drive. Somewhere in 2.1.x we added per-drive queues, and
started to play with how to share the interface bandwidth between them
fairly, in an attempt to prevent a slow device from starving a fast
device which shares the same channel.

The current algorithm in the kernel tries to measure the last request
service time of a drive, and then give the other drive the bus for
the same amount of time before taking it back from him. It also provides
service for devices capable of "disconnecting" using DSC overlap.
The patches instead try to revert to a simple "one request for drive 1",
then "one request for drive 2" round robin algorithm.

Tkil's setup is unique in that three of the four IDE devices have
real time constrains -- if we fail to service a CD-R in time, we
make a coaster. In addition to that, the fourth IDE device is actually
the source drive for all the three and shares a bus with one of them.
This kind of setup really triggers and let us see inefficiencies in
various places.

Cheers,

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/

- Next message: Richard A Nelson: "Re: problem with linux 2.2.15pre4 + Rik's VM fix"
- Previous message: Stephen C. Tweedie: "Re: 2.2.1{3,4,5pre*} VM bug found"