Re: 2.6.0-test6
Ok, I'll reply to a few minor points, then I'll shut up about it for a while
and gor research more for myself.
>It's just the kernel that needs to be 64-bit on sparc64 systems
Ok, I did take that one a bit farther than what it said. My bad.
> Stop there, if you're using an IDE interface in PIO mode you don't
> care about performace
Sorry, I should have made it clearer that this was a 'test worst case for
illustration purposes only'.
> Actually, in IDE PIO mode you can only transfer a maximum of 32-bits
> to or from the IDE device at once time, this is because the IDE data
> register is 32-bit in size.
Nope. You can transfer 16 bits. This is not a register, this is hardware.
http://www.howell1964.freeserve.co.uk/parts/ata_eide.htm
You have 16 data lines. They are single clocked.
I assume you are looking at the software interface to the IDE controller,
which, if set up correctly, will combine two 16 bit physical transfers into
one 32 bit piece of data available.
>All of the creator3D support I wrote is 32-bit and takes full advantage
> of the UPA bandwidth. 64-bits or not makes no difference wrt. to this,
> so your ignorance is showing again... The bus bandwidth of UPA
> is 64-bytes in one transfer, not 64-bits. The 64-bit transfers are
> accomplished using the UltraSPARC block load and store instructions
> that move 64-bytes at a time in and out of the floating point registers.
> These instructions are fully available in 32-bit mode.
Again, you seem to be looking at it sheerly through the software side of
things. The bus bandwidth is not 64 bytes. Bandwidth is a term of velocity:
amount over time.
http://dictionary.reference.com/search?q=bandwidth
"2. The amount of data that can be passed along a communications channel in
a given period of time. "
So, Bandwidth would have to include the clock speed of the bus AND the data
width. Which happens to be 64 bits.
http://docs.sun.com/db/doc/805-7764-12/6j7a77hhh?a=view#z400010a55fa
"The UPA 64-bit data bus provides the connection between the CPU module and
the UPA graphics. The 64-bit UPA data shares the data bus with memory
through six transceiver chips."
Clock speed of UPA varies.
> Yes, you're wrong in just about everything you're talking about
> here.
>
> Again I am reminded of why I don't post on mailing lists much
> anymore, because I always hit one of these idiotic threads...
So a request for information and clarification is...ohhh, never mind.
> The part I hate the most about threads like this is that if I don't
> waste my time sitting here correcting you, someone less knowledgable
> is going to read your posting and think there is some truth to it.
Well, in some cases I'm sure I'm wrong, in others, the designers of the
hardware would have to wrong right along with me.
>Look I've written OS's for every processor Sun has ever produced, and
> I've been doing this for 6 or 7 years.
Ok. 1996 was, after all, the year Sun introduced the Ultra workstation,
which featured the UltraSparc.
Which OS's did you write? I'm curious, and if you'd be kind enough to tell
me where to download them, I'd like to see how it runs on my SS20. Maybe
I'll switch from Solaris/Linux/NetBSD.
Maybe I'm just an old fogey who remembers the days when you tried to wring
out the performance by aligning software as closely to hardware as possible.
Maybe I think it's strange/inelegant to have a nonworking architecture in
the kernel source.
Thanks
Paul
----- Original Message -----
From: "David S. Miller" <davem@redhat.com>
To: "Paul" <paul@techcenter3000.com>
Cc: <debian-sparc@lists.debian.org>
Sent: Friday, October 03, 2003 8:20 AM
Subject: Re: 2.6.0-test6
> On Fri, 3 Oct 2003 08:02:43 -0500
> "Paul" <paul@techcenter3000.com> wrote:
>
> > Ok, I'll happily concede that 64 bit Sparcs are faster (in general) then
32
> > bit sparcs. BUT, I think that has more to do with better/more
> > [cache|architecture|MHz|optimizations|processor design] than with simple
> > '64-bittedness'.
>
> I didn't say that 64-bit sparcs performed better because they
> of thier 64-bittedness. I don't know where you got that from.
>
> > Now, the kernel may be the only thing that executes 64 bit code.
> > If so, there are two issues that would harm performance:
> > 1) The kernel talks to the hardware. So, let's take a 16 gig IDE drive
in
> > PIO mode (simply because it IS a shoddy interface).
>
> Stop there, if you're using an IDE interface in PIO mode you don't
> care about performace.
>
> > IDE can do at best a 16
> > bit transfer per cycle, only 16 bits are available on the physical
> > interface. Now, the kernel, it wants to use 64 bits. So, either we 'pad'
48
> > bits, or we do 4 transfers and combine them into one 64 bit 'word'. This
> > operation would happen at LEAST twice per operation, once for 'seek LBA'
and
> > once for 'read sector'. Apply this to to (most) common 32 bit PCI bus.
Apply
> > this to, even worse, printer I/O. (Ok, so we do offload a lot of this
onto
> > sub-processors, but the point remains the same)
> > How many applications do you run that do not EVER access ANY hardware? I
> > can't think of any except a no-op loop. even a number crunching app has
to
> > talk to memory, and the kernel controls that.
>
> Actually, in IDE PIO mode you can only transfer a maximum of 32-bits
> to or from the IDE device at once time, this is because the IDE data
> register is 32-bit in size.
>
> I don't think you understand much of this technology very well, and this
> is making this discussion beyond frustrating :(
>
> > I think our issue here may come from the fact that UltraSparc I and II
at
> > least are capable of running perfectly happily with 32bit kernels.
>
> There is not 32-bit Linux kernel for 64-bit Sparc chips, the hardware
> (especially the MMU) is very awkward to program with a 32-bit kernel
> so I never tried to implement that. Only Sun was foolish enough to
> ship something like this :)
>
> > (I have
> > these procs, among others) So why wouldn't I keep the raw speed of a
fast
> > 64bit processor that happens to be capable of running either 32 _or_ 64
bit
> > kernels AND wipe out the overhead I believe is incurred by the 64 bit
kernel
> > by running a 32 bit kernel.
>
> Actually, many of the native data types used in the Unix kernel are
> 64-bit (loff_t, block numbers, page numbers, physical addresses,
> etc.), and you still have to do the 64-bit operations on these datums
> in the 32-bit kernel.
>
> Also, with the 32-bit kernel it's several orders of magnitude harder
> to support more than a few GB of physical memory in the Linux kernel.
> With a 64-bit it's trivial.
>
> > I'm honestly not sure if the 64 bit kernel requirement for UltraSparc
III's
> > mentioned below is a hardware driven issue or a decision by Sun to
disallow
> > 32 bit kernels on III's.
> > (Please, can anyone shed light on this?)
>
> Sun woke up and finally figured out how utterly stupid it was to have
> to support and fix bugs in two different kernels for the same exact
> pieces of hardware.
>
> > 2) Userland is mostly 32 bit, if not completely. So what happens when I
make
> > a 32 bit call to the kernel that wants to receive 64 bits, and return 64
> > Bits? The kernel has to either assume 32 bitness and pad in at least one
> > direction, or decide whether it is 32 or 64 and pad, which would add
even
> > more overhead.
>
> The 32-bit Sparc application ABI has ways to deal with 64-bit types just
like
> x86 or any other 32-bit processor. When system calls are made, the 32-bit
> system call is translated into the types the 64-bit kernel natively wants.
> This translation process is surprisingly inexpensive and most of the
> time is not needed at all.
>
> > 2) Majority reported that running a 32-bit application on the 64-bit
kernel
> > requires more cycles to do alignment and byte packing operations. Thus
it is
> > reasonable that 32-bit code would run slower on the 64-bit kernel than
the
> > 32-bit kernel.
>
> That's total bullshit.
>
> Look I've written OS's for every processor Sun has ever produced, and
> I've been doing this for 6 or 7 years. And all I can say is that
everything
> you've said here is total BS, in particular this crap coming from the
> Sun managers list.
>
> > I hadn't thought about the half sized cache issue(#3), but heck,
doubling
> > your cache rarely HURTS performance.
>
> Many of the cache arguments are total bullshit because the kernel has
> to keep track of a significant number of datums using 64-bit
> types even in the 32-bit kernel.
>
> > On the flip side of this, I have to say, if you're doing heavy graphics
> > work, almost without a doubt 64 bit is for you. (Gee, the bus width of
UPA
> > for example is..taadaa-> 64 bits..theoretically one transfer)
>
> All of the creator3D support I wrote is 32-bit and takes full advantage
> of the UPA bandwidth. 64-bits or not makes no difference wrt. to this,
> so your ignorance is showing again... The bus bandwidth of UPA
> is 64-bytes in one transfer, not 64-bits. The 64-bit transfers are
> accomplished using the UltraSPARC block load and store instructions
> that move 64-bytes at a time in and out of the floating point registers.
> These instructions are fully available in 32-bit mode.
>
> > Again, if I'm wrong, please explain to me how and/or why. I'm learning
every
> > day, and I'll learn from anybody that can/will teach me.
>
> Yes, you're wrong in just about everything you're talking about
> here.
>
> Again I am reminded of why I don't post on mailing lists much
> anymore, because I always hit one of these idiotic threads...
>
> The part I hate the most about threads like this is that if I don't
> waste my time sitting here correcting you, someone less knowledgable
> is going to read your posting and think there is some truth to it.
>
Reply to: