>
>"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:
>
>> 
>> I agree with all of these points, and provide what I think is a
>> solution.  The main problem here is that the buffer is pulled off
>> the queue only based on a per device openings number.  For the
>> aic7xxx driver, the number of openings is arbitrary and based on
>> the number of tags we feel like allowing a device to consume.  This
>> just isn't enough information to ensure that all the resources we
>> need are availible.  Instead, the SCSI system should track the
>> number of controller openings and device openings and only proceed
>> if both are availible.  The SCSI system could also monitor the
>> number of openings allowed on a per device level and modulate them
>> based on rtprio or for fairness in sharing controller openings
>> among competing devices.  With this strategy, you should never
>> have to sleep and you don't need a software queue in each driver
>> (as Jason proposed).
>
>I wouldn't call this a solution so much as a restating of the problem.
>But two comments:
>
>1) At some point, you still have to allocate data structures in
>response to something happening.  Who's going to do it?  Until you get
>to the strategy routine, you don't even know that you need a buffer,
>and you don't know how many more you'll need for the I/O in progress.
>(I have two somewhat high-impact solutions for this.)
>
>2) The higher-level SCSI code has no business knowing about resource
>limits on the controller, except through an explicit feedback
>mechanism.  The device needs resources, and the controller supplies
>resources, but neither should know the internals of the other.

Instead of having the upper level SCSI code look at openings, have
it call getxs() before it dequeues the buffer instead of relying
on scsi_scsi_cmd to do the resource allocation for you.  It can
then setup its command directly in the returned xs instead of
scsi_scsi_command copying it. This removes any explicit knowlege
of the types of resources from the upper level drivers and is more
efficient to boot.

Someone has to track both the per device slots and per controller
slots, and you can either call down to the controller always, or
just track the controller openings generically, and skip the function
calls that you know will fail.  Regardless of the approach, you
still have the problem of allocating the structures, but since we
get the request for resources before the buffer is dequeued, we
can return failure status when we can't malloc and still not sleep.

I certainly don't want to pre-allocate resources when the number
of openings changes since the cost is high on some controllers and
in many cases all of those resources will never be used.  For
example, the aic7xxx driver requires ~2k of data structure space
per SCB and with SCB paging, you can have 255 of them.  I don't
see any performance penalty in demand allocation even if that means
we only malloc more structures whe we are not in an interrupt
context.  Most (all?) commands that enter the system start out in a
non-interrupt context and should be plenty of oportunities to
malloc the structures.



--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================