Messages in this thread | | | Date | Tue, 14 May 2002 17:20:19 +0100 | From | Neil Conway <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
Martin Dalecki wrote: > > Uz.ytkownik Alan Cox napisa?: > >>From an abstract hardware point of view each ide controller is a queue not > > each device. Not following that is I think the cause of much of the existing > > pain and suffering. > > Yes thinking about it longer and longer I tend to the same conclusion, > that we just shouldn't have per device queue but per channel queues instead. > The only problem here is the fact that some device properties > are attached to the queue right now. Like for example sector size and friends.
OK..
> I didn't have a too deep look in to the generic blk layer. But I would > rather expect that since the lower layers are allowed to pass > an spin lock up to the queue intialization, sharing a spin lock > between two request queues should just serialize them with respect to > each other. And this is precisely what 63 does.
(You're planning to have two queues per channel but sharing the same lock?)
On the serialisation issue: what does serialisation of the queues with respect to each other mean to you? I understand it to mean that we won't ever call the request_fn of both queues at the same time - because that's all the actual spinlock buys you. It does not IIUC mean that you can't get a call to request_fn of one queue while the other queue has lots of requests in it (which are potentially being serviced by DMA). Or does it? Does the block layer track which requests are "active" somehow?
My main question could be posed thus: am I right in thinking that we MUST track the busy-ness of the channel at all times? (and for broken chipsets, track the logical OR of both channels' busy-ness)
Neil PS: I'm hoping someone will either say "here's why you're wrong" or "you're right" RSN... - 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/
| |