On Tue, May 14 2002, Martin Dalecki wrote:
> 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.
Right, I see that as the only right way to get the right synchronization
too.
> 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.
Hmm yes, hardsect_size comes to mind. It will just have to be 'lowest
common denominator' for a while I suppose.
> 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.
I think you are mixing up two very different serialization issues. A
shared queue lock will indeed protect however much you want, but only at
the queue level. It will _not_ provide synchronization for hardware
access in any sane way, like a shared queue between two devices will.
You could alternatively move requests to an internal queue of your own
width, that would synchronize drive operations at any level you want
(you set the rules). The block layer can still sanely handle the locking
for you, the scope of that lock will just be a bit wider.
-- 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/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:23 EST