Re: [PATCH] 2.5.15 IDE 61

[Jens Axboe <axboe@suse.de>]

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