So it can. And I thought I had come up with a clever idea... (-;
>And in fact the ide layer used a global ide_lock shared between all queues
> > 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.
Yes, I understand that, could you not extend the shared lock idea to a
shared flags idea? The two could even be in the same memory allocated block
as both the lock and the flags would always be shared by the same users.
That would just now contain only QUEUE_SHARED_FLAG_BUSY but could be
extended later if the need arises.
From what I gather from the posts on this topic, this would be entirely
sufficient to fully lock both request queue handling and request submission
to the hardware while maintaining per-device queues.
I may be way off base but I would think that per-device queues are
desirable to improve the request merging abilities of the elevator. (Again,
code I haven't looked at so it may well be intelligent enough to
resort/merge requests with different destinations on the same queue but I
am sure you will tell me if this is the case. (-;)
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown-- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/