On Fri, Mar 24, 2000 at 03:27:57PM -0800, Scott Lurndal wrote:
>
> I don't believe that there are any intelisms in the driver, but
> I've not tried it on alpha myself. It came directly from qlogic
> and is based upon their master source tree (which supports most
> proprietary unices) so I suspect it will work fine.
>
Okay, cool.
> >
> > On our ES40s (quad Alpha cpus), we are seeing about 212MB/s maximum
> > throughput on the PCI bus so we shouldn't have a problem there.
>
> On a single bus? Ah, alpha - 64 bit PCI bus, right? Is it 33mhz or
> 66 mhz?
Yup, single bus. We are seeing this throughput on a Quadrics Elan
interconnect. What I am hoping to do is have my file system on one
bus and the Elan on the other bus and hopefully saturate the link on
the Elan with file I/O. I'm pretty sure these PCI busses are 33MHz.
The Elan supports 400MB/s on the wire and is capable of 66MHz so I
would think we would be seeing better performance out of it if it were
66MHz. I also think I read it was 33MHz in the owner's manual. :)
> >
> > Do you know what the chances of this stuff making its way into the
> > main Linux kernel are? It sounds to me, without having used either of
> > these patches yet, that the approach SGI is taking is a little more
> > robust and easier for developers to utilize. I would like to minimize
>
> I tend to agree with the above characterization - particularly that
> the interface via the character device is exactly the same on
> all flavors of unix. The linux /dev/raw stuff is an anomoly
> and limits one to 256 raw partitions - a significant limitation
> on large systems.
>
> Insofar as acceptance goes, I'm trying to craft the patch in
> such a way that it won't be objectionable to the community -
> but no guarantees. We are willing to work with the community
> to ensure acceptance eventually. It is likely that the XFS
> work will make use of the scsi raw stuff for performance reasons,
> so we may push it through that vehicle - xfs should be released
> shortly (perhaps next month).
>
Haha! Yeah, we are trying to do the same sort of thing with some of our
changes. Make the one that most people want to depend on something
that isn't in the kernel already. At least this way people will see
how these changes are used. If someone has a work around for us that
is already in the kernel, it is fine since I would like to avoid
bloat, but I seriously think that the Linux kernel is still in its
infancy and has a ways to go for scaling up to ASCI level HPC.
BAPper
|