In article <[EMAIL PROTECTED]
>, Dominik Stadler <[EMAIL PROTECTED]> writes
>
>Hi,
>
>As far as I understood it (Heiko, please correct me, if this isn't correct),
>the sg_2_0_35.patch allocates one distinct buffer per SCSI-Device in steps
>of exactly 32K, 64K, 128K and for more it allocates the amount needed.
>
>Every device has it's own buffer and tries to use it for the next allocation
>if the size is big enough, otherwise the buffer is thrown away and a
>suitable bigger buffer is allocated.
>
Perhaps as a compromise it would be useful to give each bus its own
buffer (I patched sg to provide an extra SG_BIG_BUFF, so that all even-
numbered host adaptors would use one buffer and all odd-numbered
adaptors another -I was using single channel adaptors).
The assumption here is that only one target is involved in data
transmission at once on any given bus -wouldn't this normally be the
case?
It seems to me that for a machine that is used intensively for burning
CDs (I'm concerned with building CD duplicators) it is acceptable to
kmalloc a large block of memory on device open[*] and hold it until the
device is closed. If there is no memory available to allocate the buffer
I would rather that the open failed rather than the first large write
failing; we may already have wasted the disc by the time we come to the
first write; obviously the disc won't be touched until the sg device is
opened.
[*] Or via an ioctl() immediately after device open, such an ioctl
specifying the size of buffer requested? This allows the application to
apply a fallback approach if it can't get the buffer: not all
applications will need a 128K buffer for talking to a device; we might
only want the table of contents etc.
Finally, I think that removing GFP_DMA will probably help (I did it for
my system), but I don't think that can be done unconditionally as there
may be people uaing ISA adaptors. Presumably there is an approved method
of finding out whether the underlying hardware is PCI-based?
John
--
John Gray | [EMAIL PROTECTED] 0121 688 8897
Azuli IT Services, Birmingham | Web, databases, custom Linux solutions
www.azuli.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
