Messages in this thread | | | Date | Wed, 15 May 2002 08:16:54 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
On Tue, May 14 2002, Anton Altaparmakov wrote: > At 15:30 14/05/02, Martin Dalecki wrote: > >Uz.ytkownik Alan Cox napisa?: > >>I think you are way off base. If you have a single queue for both hda and > >>hdb then requests will get dumped into that in a way that processing that > >>queue implicitly does the ordering you require. > >>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. > > > >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. > > Hi Martin, > > instead of having per channel queue, you could have per device queue, but > use the same lock for both, i.e. don't make the lock part of "struct queue" > (or whatever it is called) but instead make the address of the lock be > attached to "struct queue".
See request_queue_t, the lock can already be shared. And in fact the ide layer used a global ide_lock shared between all queues until just recently.
> Further if a controller is truly broken and you need to synchronize > multiple channels you could share the lock among those.
Again, this is not enough! The lock will only, at best, serialize direct queue actions. So I can share a lock between queue A and B and only one of them will start a request at any given time, but as soon as request X is started for queue A, then we can happily start request Y for queue B.
This is what the hwgroup busy flag protects right now, only one queue is allowed to mark the hwgroup busy naturally. So only when request X for queue A completes will the hwgroup busy flag be cleared, and queue B can start request Y.
-- Jens Axboe
- 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/
| |