Re: [PATCH] 2.5.15 IDE 61

[Martin Dalecki <dalecki@evision-ventures.com>]

Uz.ytkownik Neil Conway napisa?:
> Martin Dalecki wrote:
> 
>>The only problem is that having a shared lock between two queues apparently
>>doesn't imply that the queues are behaving atomic on the request level
>>among each others.
> 
> 
> Correct - both queues can be active with I/O in flight at the same
> time.  But think about it: if this weren't the case, then the older
> kernels (using global io_request_lock) would have had to serialize ALL
> I/O, one request-queue active at a time, for every single
> block-device...
> 
> 
>>Apparenty the "sublimation" of the hwgroup and overall cleanup of
>>data structures, just made many people awake and be aware of problems which
>>where there already for a very very long time...
> 
> 
> I'm not quite sure which problems you mean.  The busy flag prevents any
> clash. (But sure, if you change to per-device queues AND you ditch the
> busy flag you're screwed.) Where is the problem?

The problem is that with the busy flag on we are wasting quite
a significant amount of CPU time spinning around it for no good...

Right now I'm quite confident about the idea of just having
two queues ata_queue and atapi_queue on the channel possible
shared among two channels. This will make the CPU cycle waste
occur only in the case of channels where ATA and ATAPI devices
are mixed as master and slave. This will work becouse the
only really crucial queue property which has to be device type
specific is the hardsect size.
Quite the same design as in, well, FreeBSD.
As a second step we could do just the following - block one
of the queues if the second one is active right now... This should
be simpler than doing it on the per device level by the busy flag and
wasting CPU time around it.