Tony Chung wrote:
>
> >
> >
> > Please note that I am not *ever* inclined to include such a wasteful change
> > into my driver. Furthermore, you need to also change the code in
> > aic7xxx_alloc_scb() to go along with this change (or at least verify that
> > allocation sizes are still reasonable).
>
> May be not that wasteful if AIC7XXX_MAX_SG is a changable module paramteter?
It's still wasteful. The aic7xxx driver pre-allocates its S/G array
structures for each and every command it allows to be queued. This keeps a
swap command from resulting in a memory allocation when it is least likely to
be successful. That means that by doubling the size of the SG array, you
double the size of those pre-allocated commands. Each S/G array element is 8
bytes, so 128 elements (the default) is exactly 1K per array struct. Your mod
doubles that. And it does so for no good reason (read below for an
explanation).
> The scatter_gather/segments concept is due to a limitation of x86 platform that
> only
> allow DMA up to a 4K boundary.
Not true. My driver is happy to use S/G segments far larger than 4K in size
as long as the segments are physically contiguous. Check the SCSI clustering
code.
> So a virtual memory buffer is splitted into segments of real physcal addresses
> of 4K each
> with the first and last segments less than or equal to 4K.
Again, not so. In linux, a virtual memory buffer is copied into kernel memory
for the command structure. In that process, instead of trying to allocate
large chunks of memory equal in size to the size of the virtual buffer, we
allocate in memory chunks of a reasonable size and assemble the chunks into a
S/G array. We then walk that list of S/G elements and coalesce adjacent
buffers into single larger S/G elements (only if clustering is enabled via a
low level driver flag).
> >From /var/log/messages, current st parameters are:
> st: bufsize 32768, wrt 30720, max buffers 4, s/g segs 16.
> So the current 32k bufsize must have split into 16 segments of 4K each.
> The segments list is then transfered to the adaptor card for DMA.
>
> I know currently st/sg drivers DMA to kernel space first and then copy
> to user space later.
> Can current linux support direct DMA to user space? If Yes, then it is not that
> resource
> demanding but can Linux locked/pinned over 1MB of physical memory for a user?
2.3 kernels can do this, but it's not an answer either.
> > I'm in complete agreement with Gerard Roudier that any piece of hardware that
> > needs this kind of change to work efficiently is in need of a good firmware
> > author to get things fixed in the hardware, which is where the obvious problem
> > is.
>
> It is a tape drive versus a hard disk which may support
> linked/taged/overlap/non-sequential processing.
In unlinked/untagged/non-overlapped/sequential operations I have hard drives
here that get very good speed results without 1MB single commands. The
standard linux disk driver will only make a command that is a maximum of 64K
in size, so the 128 element S/G array I allocate is actually tuned towards
supporting the worst case disk transfer S/G array needs. I have yet to see a
good reason to change that.
> I also agree that our firmware can be improved.
> However, there are real customers that require large tape block size (1MB) which
> is allowable by SCSI-II standard
> and supported on other UNIX platforms and tape drive vendors.
I recently did a tape backup under linux. I got 276 MByte/min sustained tape
throughput on a 4Gig backup. That averages a little over 4MB/sec sustained
throughput to tape. I did it with the standard linux tape driver and smallish
tape blocks (32K I think is what the tape drive was using). That happened to
be a media speed limitation. I have no doubt that the next generation tape
backup media would be even faster.
So, my question is simple. You say that you have customers that "require" 1MB
tape block sizes. Since it's possible to make a fast tape backup device that
uses smaller tape block sizes, what exactly are the other reasons that a 1MB+
block size is needed? If you can give me some reasons why this is needed
other than performance on your particular tape backup device then I might be
quite a bit more lenient on what you are asking for, at least as it applies to
my specific device driver.
> It will be bad if a tape created by NT or Solaris cannot be read by Linux. If
> you only read 32K on
> a 1MB tape block, you can only get 32K data and then the next 32K scsi read will
> start on the next 1MB block.
> So you cannot get back that (1MB-32K) data!
>
> Thanks again.
>
> --
> =============================
> Tony Chung
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
--
Doug Ledford <[EMAIL PROTECTED]>
Opinions expressed are my own, but
they should be everybody's.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
