Messages in this thread | | | Date | Tue, 14 May 2002 15:51:47 -0700 | From | Mike Fedyk <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
On Tue, May 14, 2002 at 05:47:21PM +0100, Neil Conway wrote: > Jens Axboe wrote: > > To really serialize operations the queue _must_ be shared with whoever > > requires serialiation. > > Why will this help? The hardware can still be doing DMA on hda while > the queue's request_fn is called quite legitimately for a hdb request - > and the IDE code MUST impose the serialization here to avoid hitting the > cable with commands destined for hdb. (For example, by waiting for > !channel->busy.)
First of all, why do you think that when a new request is queued it hits the hardware immediately? I mean, it is a queue after all...
I'd immagine that you would have one function that is triggered by DMA completion interrupts that reads the queue and starts the hardware for a request.
While that function is operating the hardware, it should't care about the queue, so you can add requests to the queue for both (think hda and hdb) devices on the channel.
channel = ide cable
There is a hardware limitation for IDE in that it doesn't allow more than one device to be active on one channel at a time. So, there is no point in having seperate queues for each device on the channel since the two queues would just be waiting on each other, and would probably end up a pretty big mess.
If a host controller (think ide chipset with multiple channels 2,4,8 etc) needs serialization between multiple channels, then you can simply use one queue for each group of channels that need searialization between each other.
Mike
(OT, now that IDE is getting TCQ, will the main difference between SCSI and IDE be just the number of devices per cable? I'm not talking electrically or about the protocol, but mainly performance from say the block layer's perspective) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |