Messages in this thread | | | Date | Wed, 15 May 2002 11:42:35 +0200 | From | Martin Dalecki <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
Uz.ytkownik Anton Altaparmakov napisa?: > At 07:16 15/05/02, Jens Axboe wrote: > >> On Tue, May 14 2002, Anton Altaparmakov wrote: >> > 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. > > > /me looks. > > 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 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. > > > 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.
The clean solution whould be to make it possible to be able to use multiple hardsect and friend on a single queue. Becouse then one could just use the same queue for all operations.
But... wait a minute. The only really problematic case where the queue properties differ is the case where we have a disk and ATAPI device mixed on the same channel. Hmm what about using two distinguished queues on a channel - one for ATAPI and the second for ATA requests then? In esp. since it's quite easy to identify ATAPI request as beeing in flight. Hmm... the longer I think about it the more apeal this solution has to me.
> 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. (-;) > > Best regards, > > Anton > >
-- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R
- 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/
| |