From: drew@ophelia.cs.colorado.edu (Drew Eckhardt) Subject: Re: AHA1542B/SCSI performance and cross compiling Date: 24 Jun 1992 18:14:51 GMT
In article <1992Jun24.165310.24778@arbi.Informatik.Uni-Oldenburg.DE> Andreas.Mengel@arbi.informatik.uni-oldenburg.de (Andreas Mengel) writes:
>Hi Linuxers,
>
>I've just got two simple questions concerning this great OS:
>
>1) Is there a chance the SCSI-performance will get better in the next few weeks,
> as for now I have to say that it is really horrible (using the AHA1542B and
> a Wren III with 150MB). It does about 50KB (yes fifty) per second now and
> when writing to the disk, i.e. whenever either update or I sync, the whole
> machine just hangs for a while which is quite annoying if you try to compile
> larger sources. I would like to increase the performance myself, but I just
> don't know how it could be done (cannot even program assembler and do not
> completely understand how the driver works). So perhaps if any of you out
> there (I know there must be more using the AHA1542B) would be so kind and do
> something about it ...
> Perhaps even someone from Adaptec is reading this group and could give some
> useful hints.
This has been fixed, and will be in the interim SCSI release this evening.
When I did the SCSI drivers, I put in hooks for non-interrupt driven
lowlevel drivers to ease development, and because I'd had problems
getting documentation on my SCSI board's interrupts. Naturally, everybody
used these for development, because conceptually non-interrupt
driven drivers are easier to write than interrupt driven
drivers. The down side of having a non-interrupt driven driver
is that processes are not scheduled while the I/O is happening,
resulting in both piss-poor multi-tasking performance (no other
processes are scheduled during the I/O), and a measured throughoutput decrease
to 10-50% of the level attained with the interrupt driven drivers.
You'll be happy to hear that the Adaptec lowlevel driver fared
especially well with the minor changes required to make it
interrupt driven - Tommy Thorn measured an increase from 45-50K/s to
450-500k/s with his adaptec driver, although he said not to put
too much into those numbers.
I measured an increase from 45k/s to 100k/s on the seagate
driver.
Beyond that, nothing more will happen until the "new revision" of
the SCSI drivers is out. These are designed the way I should have
done them in the begining. Performance increasing changes include
support for scatter/gather, and one outstanding command
per LUN. All of the code has been cleaned up, especially
the error handling code, a uniform request structure
is used throughout the driver stack, which works for
interrupt and non-interrupt driven hosts, and the
routines lost some weight while gaining functionality.
On my system, I saw a 6 fold improvement when the scatter / gather
code was added to the hd.c driver, so I expect similar improvements
with the SCSI code.
>2) I have just tried to set up gcc2.2.2 an a sparc2 for cross-compiling linux-
> sources using the patches and hints contained in the file gcc-2.1.tar.Z
> on banjo. I have to say that all patching and compiling went very smoothly
> and I can even produce code which looks to linux like an executable (file
> says something like "Gcc2.1 pure demand paged executable" if memory serves
> me right) but when I try to start it I just get a general protection fault
> and a core (sorry, stupid me doesn't know how to use gdb to track it down).
> I have used the 2.11c libraries and include-files from banjo to compile.
> Any idea what I did wrong ???
Make sure that permissions on the shared library are read / execute? all.
As far as tracking down where the core dump occurs, compile it
with the -g flag. Run it, or run it in gdb. If you run it
"standalone", after it dumps core, invoke gdb with
gdb a.out core
where a.out is the name of the executable. Note that you need a gdb
that supports core files.
It will show the line where it dumped core. You can then use
backtrace to see the call stack, print to dump variables, etc.
>
>Ob. Praise: Thank you Linus for this great work.
>Ob. Praise2: Thank you Drew for the existing driver. Works fine, but is just a l
> little slow :-)
Thank Tommy Thorn for the Adaptec Driver, I just did the scsi disk,
midlevel SCSI pseudo-driver, and Seagate lowlevel driver.