Re: 2.6.0-test6
Let's see, the first and most obvious issue would be transferring 64 bit
pointers per cycle instead of two 32 bit pointers in the same cycle. Sure,
if I had a large enough data set, it would speed things up greatly.
I have to ask though, what does a 64 bit kernel have to do with processor
speed? Is there something I'm not aware of where the cpu actually slow it's
clock speed down executing 32 bit code? If so, why NOT move userland to 64
bit?
The following is about Solaris SW but Sparc HW.
<copied from sun_manager list,
http://aa11.cjb.net/sun_managers/2000/09/msg00619.html>
> >(1) am I correct that 32-bit and 64-bit kernel are imcompatible at
> > binary code level (i.e. we need dual installation of all s/w) ?
>
> No, you are incorrect.
>
> All 32 bit applications continue to run on a 64 bit kernel.
>
> Only applications specifically compiled for UltraSPARC (whether 32 bit
> or 64 bit compilation is used) will not run on non-Ultra hardware; only
> applications specifically compiled for 64 bit will not run on 32 bit
kernels.
>
> (When "file foo" says something that includes "ELF 64-bit", it will only
> run on a 64 bit kernel; when "file foo" says something that
> includes "V8+ Required" or "UltraSPARC1 Extensions Required", then it
> will only run on UltraSPARC (on 32 or 64bit kernels))
>
> All UltraSPARC-I and -II systems can have both kernels installed
> and boot either fromteh same installation.
>
> UltraSPARC-III systems can only boot 64 bit kernels but will run
> 32 bit apps.
>
> Lowest common denomination compilations for "32 bit, SPARC v8"
> work on all SPARC hardware. (V7 hardware emulates V8 instructions in
> the kernel)
I'm not a sparc internals guru, but common sense tells me that moving 64
bits instead of 32 (especially if I only need 8) is going to be slower (not
to mention upping phys mem requirements.) Now, if there is built in
'prediction' then we get a boost, but start running into the x86 type 'cache
miss' performance hits, and again, we're back to transferring dbl the word
size we really need.
Please, if I've got this wrong, let me know, and please explain why. I'm not
being sarcastic, I really would like to know.
Thanks
Paul
----- Original Message -----
From: "David S. Miller" <davem@redhat.com>
To: "Paul" <paul@techcenter3000.com>
Cc: <bcollins@debian.org>; <debian-sparc@lists.debian.org>
Sent: Friday, October 03, 2003 3:23 AM
Subject: Re: 2.6.0-test6
> On Thu, 2 Oct 2003 18:57:43 -0500
> "Paul" <paul@techcenter3000.com> wrote:
>
> > Personally, I prefer 32 bit, all marketroid blathering to the contrary.
If I
> > had a huge database or was simulating weather/gnabgig/etc, then it'd be
> > worthwhile. Otherwise, the overhead of 64 bit just isn't quite worth it
to
> > me.
>
> I cry when I read posting like this...
>
> What are you talking about? All the userland is 32-bit even on
> sparc64 systems, so you're getting all of the benefit of the faster
> processor (all of your sparc64 systems have faster cpus than nearly
> any sparc32 machine ever produced) without the bloat of 64-bit
> userland.
>
> It's just the kernel that needs to be 64-bit on sparc64 systems.
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
Reply to: