Re: [PATCH] 2.5.15 IDE 61

[Andre Hedrick]

Arbitrate your incoming interrupts.  In the classic dual interrupt you are
scott free for the most part, erm interrupt sharing will eat you alive.
HBA's w/ N channels will eat the BLOCK Layer of lunch and purge it for
dinner.  If you notice SCSI originally had queues based on the HBA for a
reason,  one can read all day long form any devices on the chain, but
issue a write and everything grinds to a halt.

The original taskfile driver was to permit set and go calls of a
multi-level queues.  It was also to permit fake local tags with additional
load balancing on the channel w/ mixed devices and/or w/ broken hardware
force a simplex behavior.

hwif[n].drives[m].queue     \
			     --- hwif[n].queue
hwif[n].drives[m+1].queue   /
							hwgroup.queue
hwif[n+1].drives[m].queue   \
			     --- hwif[n+1].queue
hwif[n+1].drives[m+1].queue /

 
In the future:

hwif[0].drives[0].queue   <> hwif[0].queue
hwif[1].drives[0].queue   <> hwif[1].queue
hwif[2].drives[0].queue   <> hwif[2].queue
...
hwif[n-1].drives[0].queue <> hwif[n-1].queue
hwif[n].drives[0].queue   <> hwif[n].queue

Where "n" ranges from 2->20  all on the same hwgroup.queue

Now how is your spinlock going to process all of those in parallel?
I can tell you first hand, it can't.

Cheers,

On Tue, 14 May 2002, Neil Conway wrote:

> Alan Cox wrote:
> > If the queue abstraction is right then the block layer should do all the
> > synchronization work that is required. 
> 
> I think you're wrong Alan.  Take a good IDE chipset as an example: both
> channels can be active at the same time, but you still can't talk to one
> drive while the other drive on the same channel is DMAing.
> 
> I'm not a block layer expert, but it appears to me that the block layer
> only synchronises requests by use of the spinlock.  If I'm right, then
> the block layer has no way of knowing that hda is DMAing when a request
> is initiated for hdb.  This was the whole reason (as I see it) that
> hwgroup->busy existed: to prevent attempts to use the same IDE cable for
> two things at the same time.
> 
> It doesn't matter how you perform the queue abstraction in this case:
> the fact that the device+channel+cable is busy in an asynchronous manner
> makes it impossible for the block layer to deal with this.  [[Or am I
> way off base?!]]
> 
> The right way is the way it is being done at present surely: if the busy
> flag on the hwgroup is set, then ide_do_request() just returns.  (NB:
> When I say "right way", I don't mean to imply that the code is elegant,
> desirable, or even bug-free, just that it correctly handles this busy
> state.)
> 
> >It may cost a few cycles on the odd
> > case you can do overlapped command setup but that versus a nasty locking
> > mess its got to be better to lose those few cycles.
> 
> Well, Jens and others are busy implementing TCQ where things are just so
> much easier to fsck up :-))
> 
> > I don't even Martin here, the ide locking is currently utterly vile
> 
> Agreed, but surely with some concerted effort we can truly fix the IDE
> code.  Can't be beyond us all can it?
> 
> Neil
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group