[gentoo-user] mtune=k6-2 and a *small* upgrade

[gentoo-user] mtune=k6-2 and a *small* upgrade

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

Hi All,

    An interesting theoretical question. I have a K6-2 with a SATA card 
sitting in it, with two drives, which are happily soft-mirrored, with 
LVM layered on top, and a nice big iSCSI partition that gets shared to 
my laptop whenever it's home.....

    It runs postfix (with all the associated tools, amavisd, sqlgrey, 
spamassassin), mysql, apache, IMAP etc etc etc I would *really* not like 
to have to re-install, and re-set up.

    I am thinking of upgrading the dead PC I have in the house, that 
would go to an Athlon 64X2, which would be more than adequate for a 
desktop, even with all of these services running.

    So, the question. What would I have to do in order that I could 
build the new system, shutdown the old one, pull the drives, plug them 
into the new one, turn it on, and have it actually work?

    Obviously a kernel recompile (probably make allyesconfig, or 
makeallmodconfig), and a lilo change (since this machine won't boot from 
SATA since the spec didn't exist when it was first turned on...).

    But what else? Will mtune=k6-2 make executables that will run on an 
Athlon 64? Anyone tried this? Would I get to a point where I could make 
-e world and have a nice working system?

Regards


Anthony


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Alan McKinnon]

On Tuesday 08 April 2008, Anthony Metcalf wrote:
>     But what else? Will mtune=k6-2 make executables that will run on
> an Athlon 64? Anyone tried this? Would I get to a point where I could
> make -e world and have a nice working system?

k6 is 32 bit right?

There's no sane upgrade path to amd64, looks like you are in for a 
reinstall

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Alan McKinnon wrote:
> On Tuesday 08 April 2008, Anthony Metcalf wrote:
>   
>> � � But what else? Will mtune=k6-2 make executables that will run on
>> an Athlon 64? Anyone tried this? Would I get to a point where I could
>> make -e world and have a nice working system?
>>     
>
> k6 is 32 bit right?
>
> There's no sane upgrade path to amd64, looks like you are in for a 
> reinstall
>
>   
Yes, 32bit, and Athlon 64s ran x86 last I heard :)

The 64bit argument is one I will have to consider more deeply, but 
certainly in the near term, I won't gain anything from it, as I don't do 
*any* of the things the extended memory range is good for, and don't 
need more than 4GB RAM.......

Later when I upgrade to a phenom, and stick 1GB RAM per core in there, 
then yeah, I will probably recompile into 64bit, but that can be done in 
a chroot, and migrated fairly easily I would expect, so long as the 
system is running.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Tue, 08 Apr 2008 15:43:16 +0100, Anthony Metcalf wrote:

> Later when I upgrade to a phenom, and stick 1GB RAM per core in there, 
> then yeah, I will probably recompile into 64bit, but that can be done
> in a chroot, and migrated fairly easily I would expect, so long as the 
> system is running.

The chroot will be running on a 32 bit kernel. At some time you will have
to reinstall to get 64 bit, only you can decide when is the best time to
get it done with.


-- 
Neil Bothwick

"Mr. Worf, scan that ship." "Aye Captain. 300 dpi?"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Alan McKinnon]

On Tuesday 08 April 2008, Anthony Metcalf wrote:
> Alan McKinnon wrote:
> > On Tuesday 08 April 2008, Anthony Metcalf wrote:
> >> � � But what else? Will mtune=k6-2 make executables that will run
> >> on an Athlon 64? Anyone tried this? Would I get to a point where I
> >> could make -e world and have a nice working system?
> >
> > k6 is 32 bit right?
> >
> > There's no sane upgrade path to amd64, looks like you are in for a
> > reinstall
>
> Yes, 32bit, and Athlon 64s ran x86 last I heard :)
>
> The 64bit argument is one I will have to consider more deeply, but
> certainly in the near term, I won't gain anything from it, as I don't
> do *any* of the things the extended memory range is good for, and
> don't need more than 4GB RAM.......
>
> Later when I upgrade to a phenom, and stick 1GB RAM per core in
> there, then yeah, I will probably recompile into 64bit, but that can
> be done in a chroot, and migrated fairly easily I would expect, so
> long as the system is running.

OK, so it's 32 bit on an amd64 you'll be doing

I would reconfigure the kernel and include things that you know ought to 
be there. Then move the disks over and see if it boots. Rinse, repeat, 
till it does.

Now the existing system should work with your new hardware and you can 
update your CFLAGS and 'emerge -e world' at your leisure.

That's the theory at least anyway :-)

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]


On Tue, 2008-04-08 at 15:43 +0100, Anthony Metcalf wrote:
> Alan McKinnon wrote:
> > On Tuesday 08 April 2008, Anthony Metcalf wrote:
> >   
> >> � � But what else? Will mtune=k6-2 make executables that will run on
> >> an Athlon 64? Anyone tried this? Would I get to a point where I could
> >> make -e world and have a nice working system?
> >>     
> >
> > k6 is 32 bit right?
> >
> > There's no sane upgrade path to amd64, looks like you are in for a 
> > reinstall
> >
> >   
> Yes, 32bit, and Athlon 64s ran x86 last I heard :)
> 
> The 64bit argument is one I will have to consider more deeply, but 
> certainly in the near term, I won't gain anything from it, as I don't do 
> *any* of the things the extended memory range is good for, and don't 
> need more than 4GB RAM.......
> 
> Later when I upgrade to a phenom, and stick 1GB RAM per core in there, 
> then yeah, I will probably recompile into 64bit, but that can be done in 
> a chroot, and migrated fairly easily I would expect, so long as the 
> system is running.
> 

It's not just the memory. Using 64bit gives your CPU some more registers
thus (possibly) making him faster and it speeds up 64bit calculations
(e.g. double precision floating point).

I don't think you'll need this for your purposes but I just wanted to
say: It's not just the 4 Gig.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Alan McKinnon wrote:
> OK, so it's 32 bit on an amd64 you'll be doing
>   

Initially yes, I'll look into 64bit as need arises.....
> I would reconfigure the kernel and include things that you know ought to 
> be there. Then move the disks over and see if it boots. Rinse, repeat, 
> till it does.
>   

Well, more likely, break the mirror, pull a disk, and test on the new 
machine, if it works, great, take the old machine down, and move the 
remaining disk across and drop onto the network, and start the process 
to change the cflags and emerge -e world...

If not, then most likely move the disk back, let the mirror rebuild, and 
do a fresh install on new disks...
> Now the existing system should work with your new hardware and you can 
> update your CFLAGS and 'emerge -e world' at your leisure.
>
> That's the theory at least anyway :-)
>
>   
Well, exactly. That is the theory. I want to know the likelihood of 
success. I know that using mtune=k6-2 means it won't run on anything 
before a k6-2, and most likely not on anything Intel, due to the symbols 
and optimisations used. What I want is some idea of the chance it will 
run on a *later* AMD processor. Will an Athlon honour the k6-2 
optimisations?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Tue, 08 Apr 2008 16:02:50 +0100, Anthony Metcalf wrote:

> Well, exactly. That is the theory. I want to know the likelihood of 
> success. I know that using mtune=k6-2 means it won't run on anything 
> before a k6-2, and most likely not on anything Intel, due to the
> symbols and optimisations used. What I want is some idea of the chance
> it will run on a *later* AMD processor. Will an Athlon honour the k6-2 
> optimisations?

If you have the time before the transition, you could set CFLAGS to
something really generic, like -mcpu=i586 and emerge -e system, as well
as recompiling the kernel. Then move the disks over. That way, you'll
know that your toolchain and portage will work, which is all you need to
get everything else going.


-- 
Neil Bothwick

If a book about failures doesn't sell, is it a success?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Neil Bothwick wrote:
> On Tue, 08 Apr 2008 16:02:50 +0100, Anthony Metcalf wrote:
>
>   
>
> If you have the time before the transition, you could set CFLAGS to
> something really generic, like -mcpu=i586 and emerge -e system, as well
> as recompiling the kernel. Then move the disks over. That way, you'll
> know that your toolchain and portage will work, which is all you need to
> get everything else going.
>
>
>   
May be a good idea...

Only problem with that is that his ageing system doesn't like to compile 
gcc any more. I get segfaults on anything that takes more than about 40 
minutes to compile.

One of the reasons for moving it. :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Shawn Haggett]

Anthony Metcalf wrote:
> Alan McKinnon wrote:
>> Now the existing system should work with your new hardware and you can 
>> update your CFLAGS and 'emerge -e world' at your leisure.
>>
>> That's the theory at least anyway :-)
>>
>>   
> Well, exactly. That is the theory. I want to know the likelihood of 
> success. I know that using mtune=k6-2 means it won't run on anything 
> before a k6-2, and most likely not on anything Intel, due to the symbols 
> and optimisations used. What I want is some idea of the chance it will 
> run on a *later* AMD processor. Will an Athlon honour the k6-2 
> optimisations?

There's two points that come to mind.

1) mtune is a request for the compiler to make the code more suited to 
the given processor, but without breaking compatibility. march is 
telling the compiler, do everything you can to make this code fastest on 
this processor.

 From the GCC docs for 4.2.3:
"-mtune=cpu-type: Tune to cpu-type everything applicable about the 
generated code, except for the ABI and the set of available instructions."
"-march=cpu-type: Generate instructions for the machine type cpu-type. 
The choices for cpu-type are the same as for -mtune. Moreover, 
specifying -march=cpu-type implies -mtune=cpu-type."

So mtune shouldn't be using any instructions that are in K-6 that 
weren't in a 386.

2) I believe x86 hardware never goes backwards. That is, if a new 
feature is added, all future versions of the chip have that feature, 
just with more added. Of course Intel and AMD both have their separate 
additions, but since your staying with AMD, moving to a new processor 
shouldn't break anything (even if you had used march).

Disclaimer: I'm not an expert on hardware architectures or compilers, so 
I might be wrong.

Shawn
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] mtune=k6-2 and a *small* upgrade

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

Shawn Haggett wrote:
>
> There's two points that come to mind.
>
> 1) mtune is a request for the compiler to make the code more suited to 
> the given processor, but without breaking compatibility. march is 
> telling the compiler, do everything you can to make this code fastest 
> on this processor.
>
> From the GCC docs for 4.2.3:
> "-mtune=cpu-type: Tune to cpu-type everything applicable about the 
> generated code, except for the ABI and the set of available 
> instructions."
> "-march=cpu-type: Generate instructions for the machine type cpu-type. 
> The choices for cpu-type are the same as for -mtune. Moreover, 
> specifying -march=cpu-type implies -mtune=cpu-type."
>
> So mtune shouldn't be using any instructions that are in K-6 that 
> weren't in a 386.
>
> 2) I believe x86 hardware never goes backwards. That is, if a new 
> feature is added, all future versions of the chip have that feature, 
> just with more added. Of course Intel and AMD both have their separate 
> additions, but since your staying with AMD, moving to a new processor 
> shouldn't break anything (even if you had used march).
>
> Disclaimer: I'm not an expert on hardware architectures or compilers, 
> so I might be wrong.
>
> Shawn

Thanks Shawn, that's probably the best answer I'm going to get, I doubt 
many of the AMD chip designers hang around here... :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]