Debian's Kernel 2.6.24 and future versions: Use amd64 or 686?
ANT...@zimage.com
2.6.24. I assume this will be like this for future versions.
I am planning to upgrade my Kernel from 2.6.22-1-k7. Do I use amd64 or
686? I am not planning to use any 64-bit stuff on my old Athlon 64 3200+
754 single core machine (512 MB of RAM (will add 512 MB soon)) and X2
4600+ machine (2 GB of RAM).
Are there any advantages and disadvantages between 686 and amd64 beside
being able to use more memory which I doubt I am going to (2 GB is
enough). My machines are mainly workstation to do simple tasks like Web
browsing, e-mails, watch videos, newsgroups in Pan and tin, chat/IM, a
simple private server, etc. I recall using 64-bit requires more
libraries or something and lack some stuff (e.g., Adobe Flash).
Thank you in advance. :)
--
"We are anthill men upon an anthill world." --Ray Bradbury
/\___/\
/ /\ /\ \ Phillip (Ant) @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Please remove ANT if replying by e-mail.
( )
Aragorn
> Hello. I noticed Debian doesn't make AMD K7 Kernels anymore as of
> 2.6.24. I assume this will be like this for future versions.
>
> I am planning to upgrade my Kernel from 2.6.22-1-k7. Do I use amd64 or
> 686?
Either will work if your CPU is 64-bit capable. ;-)
> I am not planning to use any 64-bit stuff on my old Athlon 64 3200+
> 754 single core machine (512 MB of RAM (will add 512 MB soon)) and X2
> 4600+ machine (2 GB of RAM).
Why not? Why buy a 64-bit machine and then run a 32-bit operating system on
it?
> Are there any advantages and disadvantages between 686 and amd64 beside
> being able to use more memory which I doubt I am going to (2 GB is
> enough).
Well, the /AMD64/ kernels are more likely to contain some processor-specific
code optimizations than a generic /i686/ kernel, eventhough there is a wide
enough diversity among 64-bit processors as well and so even an /AMD64/
kernel will not be fully optimized for your hardware.
The only way to really optimize your kernel for your hardware is to
reconfigure it and recompile it yourself, and then you may even want to
consider using a vanilla kernel from /kernel.org/ - currently at release
2.6.25 - than a Debian-patched kernel.
> My machines are mainly workstation to do simple tasks like Web
> browsing, e-mails, watch videos, newsgroups in Pan and tin, chat/IM, a
> simple private server, etc. I recall using 64-bit requires more
> libraries or something and lack some stuff (e.g., Adobe Flash).
No, 64-bit distributions do not need more libraries, although they may come
with a set of 32-bit libraries for certain proprietary software that does
not exist in 32-bit versions yet.
However, Adobe Flash can be used in 32-bit form with /nspluginwrapper/
inside a 64-bit browser, or natively in 32-bit form inside a 32-bit browser
- this is what you would need the extra libraries for - and there also is a
- granted - less functional FOSS alternative, i.e. GNU Gnash.
On the other hand, it's quite feasible to use a 64-bit kernel underneath an
otherwise entirely 32-bit operating system, as long as the kernel supports
32-bit compatibility, and since you're looking at a distribution-specific
kernel, this kernel will have 32-bit compatibility enabled by default.
--
Aragorn
(registered GNU/Linux user #223157)
Aragorn
> No, 64-bit distributions do not need more libraries, although they may
> come with a set of 32-bit libraries for certain proprietary software that
> does not exist in 32-bit versions yet.
^^^^^^
That should of course read "... does not exist in 64-bit versions yet".
Those damn typo gremlins... :p
Ant
>> Hello. I noticed Debian doesn't make AMD K7 Kernels anymore as of
>> 2.6.24. I assume this will be like this for future versions.
>>
>> I am planning to upgrade my Kernel from 2.6.22-1-k7. Do I use amd64 or
>> 686? I am not planning to use any 64-bit stuff on my old Athlon 64 3200+
>> 754 single core machine (512 MB of RAM (will add 512 MB soon)) and X2
>> 4600+ machine (2 GB of RAM).
>>
>> Are there any advantages and disadvantages between 686 and amd64 beside
>> being able to use more memory which I doubt I am going to (2 GB is
>> enough). My machines are mainly workstation to do simple tasks like Web
>> browsing, e-mails, watch videos, newsgroups in Pan and tin, chat/IM, a
>> simple private server, etc. I recall using 64-bit requires more
>> libraries or something and lack some stuff (e.g., Adobe Flash).
>>
>> Thank you in advance. :)
>
> I use the i686 kernel for my AMD Athlon 64
How come not amd64 kernel? Any reasons?
--
"The little ant at its hole is full of courage." --African
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.home.dhs.org (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Remove ANT from e-mail address: phi...@earthlink.netANT
( ) or ANT...@zimage.com
Ant is currently not listening to any songs on his home computer.
Ant
>> Hello. I noticed Debian doesn't make AMD K7 Kernels anymore as of
>> 2.6.24. I assume this will be like this for future versions.
>>
>> I am planning to upgrade my Kernel from 2.6.22-1-k7. Do I use amd64 or
>> 686?
>
> Either will work if your CPU is 64-bit capable. ;-)
>
>> I am not planning to use any 64-bit stuff on my old Athlon 64 3200+
>> 754 single core machine (512 MB of RAM (will add 512 MB soon)) and X2
>> 4600+ machine (2 GB of RAM).
>
> Why not? Why buy a 64-bit machine and then run a 32-bit operating system on
> it?
Well, I don't have the room or feel like reinstalling my Debian to have
fully 64-bit. I was only interested in the Kernel part.
>> Are there any advantages and disadvantages between 686 and amd64 beside
>> being able to use more memory which I doubt I am going to (2 GB is
>> enough).
>
> Well, the /AMD64/ kernels are more likely to contain some processor-specific
> code optimizations than a generic /i686/ kernel, eventhough there is a wide
> enough diversity among 64-bit processors as well and so even an /AMD64/
> kernel will not be fully optimized for your hardware.
Ah, interesting. I wonder why there aren't more optimized Kernels for
the newer 64-bit processors.
> The only way to really optimize your kernel for your hardware is to
> reconfigure it and recompile it yourself, and then you may even want to
> consider using a vanilla kernel from /kernel.org/ - currently at release
> 2.6.25 - than a Debian-patched kernel.
True. I wasn't interested in doing that detailed. If I did and had free
time, I would use Gentoo. :) I remember doing it for old Red Hat Linux
7.1(?) and man that was a pain to do Kernel compilation and tweakings
even if I had plenty of free time.
>> My machines are mainly workstation to do simple tasks like Web
>> browsing, e-mails, watch videos, newsgroups in Pan and tin, chat/IM, a
>> simple private server, etc. I recall using 64-bit requires more
>> libraries or something and lack some stuff (e.g., Adobe Flash).
>
> No, 64-bit distributions do not need more libraries, although they may come
> with a set of 32-bit libraries for certain proprietary software that does
> not exist in 32-bit versions yet.
Interesting. So if I replace my old AMD-K7 Kernel with the 64-bit one,
reboot, everything should work fine without any problems? No need to
tweak or anything?
> However, Adobe Flash can be used in 32-bit form with /nspluginwrapper/
> inside a 64-bit browser, or natively in 32-bit form inside a 32-bit browser
> - this is what you would need the extra libraries for - and there also is a
> - granted - less functional FOSS alternative, i.e. GNU Gnash.
I can't use GNU Gnash since it is slow, I watch a lot of online videos,
etc. Is using /nspluginwrapper/ with Adobe Flash v9 complicated to do in
IceApe, IceWeasel, etc.?
> On the other hand, it's quite feasible to use a 64-bit kernel underneath an
> otherwise entirely 32-bit operating system, as long as the kernel supports
> 32-bit compatibility, and since you're looking at a distribution-specific
> kernel, this kernel will have 32-bit compatibility enabled by default.
Good. Thanks.
--
"The little ant at its hole is full of courage." --African
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.home.dhs.org (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
Andrew Halliwell
>> Are there any advantages and disadvantages between 686 and amd64 beside
>> being able to use more memory which I doubt I am going to (2 GB is
>> enough).
>
> Well, the /AMD64/ kernels are more likely to contain some processor-specific
> code optimizations than a generic /i686/ kernel,
There's a bit more to it than that....
x86-64 is more than just a wider address bus, it also contains a shedload
more cpu instructions, such as SSE3, iirc. There're also a lot more
registers available in 64bit mode. Which means less fetching from RAM during
calculations.
These enhancements may (in some situations) make it faster...
But I think the general consensus is, speed is generally slightly slower
because 64 bit applications tend to be slightly bigger due to the extended
instruction set and data-width taking more memory/disk space.
If you don't need more than 4gig of RAM, chances are, you're fine in 32 bit
mode, and may even be slightly better off, performance wise.
--
| spi...@freenet.co.uk | Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell BSc | operating system originally coded for a 4 bit |
| in |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
Hadron
Andrew Halliwell <spi...@ponder.sky.com> writes:
> Aragorn <ara...@chatfactory.invalid> wrote:
>>> Are there any advantages and disadvantages between 686 and amd64 beside
>>> being able to use more memory which I doubt I am going to (2 GB is
>>> enough).
>>
>> Well, the /AMD64/ kernels are more likely to contain some processor-specific
>> code optimizations than a generic /i686/ kernel,
>
> There's a bit more to it than that....
> x86-64 is more than just a wider address bus, it also contains a shedload
> more cpu instructions, such as SSE3, iirc. There're also a lot more
> registers available in 64bit mode. Which means less fetching from RAM during
> calculations.
>
> These enhancements may (in some situations) make it faster...
> But I think the general consensus is, speed is generally slightly slower
> because 64 bit applications tend to be slightly bigger due to the extended
> instruction set and data-width taking more memory/disk space.
This was hotly contested by some in comp.os.linux.advocacy but is
effectively correct. I saw no speed improvement in 64 bit over 32 bit
and just suffered from a far less stable system.
>
> If you don't need more than 4gig of RAM, chances are, you're fine in 32 bit
> mode, and may even be slightly better off, performance wise.
And certain things like flash do not work properly.
See:
http://groups.google.com/group/comp.os.linux.advocacy/browse_thread/thread/1f5d987c45c9499c
It is however getting better.
--
<wolfgang> the problem with the 'go find a real girl' admonition is
that so few of them actually have naked transformation
sequences
<reality> Dude, my girlfriend changes like four times a day
The Natural Philosopher
I think this is largely correct: I had this choice to make..for a
moderately loaded server.
Looking at some of the problems associated with the 64 bit kernels, and
realizing that by and large my actual applications were not hugely
computationally intensive, but more disk I/O bound, there seemed little
point in taking the small risk of a 64 bit kernel and libraries.
If I were building a massive server to handle many processes, then yes,
4gig RAM plus, and a 64 bit kernel would be indicated.
Or a desktop to do graphics work.
Mark T.B. Carroll
> Hadron wrote:
(snip)
>> This was hotly contested by some in comp.os.linux.advocacy but is
>> effectively correct. I saw no speed improvement in 64 bit over 32 bit
>> and just suffered from a far less stable system.
>>
>> Andrew Halliwell <spi...@ponder.sky.com> writes:
>>
>>> If you don't need more than 4gig of RAM, chances are, you're fine in 32 bit
>>> mode, and may even be slightly better off, performance wise.
>>
>> And certain things like flash do not work properly.
(snip)
> I think this is largely correct: I had this choice to make..for a
> moderately loaded server.
>
> Looking at some of the problems associated with the 64 bit kernels, and
> realizing that by and large my actual applications were not hugely
> computationally intensive, but more disk I/O bound, there seemed little
> point in taking the small risk of a 64 bit kernel and libraries.
This has been quite interesting for me to read. I've been running
AMD-based (Opteron and Athlon) systems for years, at home and at work,
with 64-bit kernels and not run into any problems, with stability or
otherwise, that were caused by doing that. For instance, our
twin-dualcore-CPU (two Opteron 275s) compute server has been rock-solid.
My experience with 64-bit Intel has been more recent (for example, I am
writing this on a T5200 system that can't be much over a year old, but
for that I am using CONFIG_MCORE2) but also very good.
I have flash working just fine with the help of Debian's ia32-libs
package. (-:
I will, however, happily admit that I tend to be unusually lucky when I
run new things (for example, I've been running kernel 2.6.24 for quite
some time now), that even our servers at work are fairly lightly loaded
(I try to overspec them to avoid future headaches), and that I can't
claim to have measured any actual speed improvement from choosing 64-bit
instead of 32-bit. So I may have dodged some problems without really
gaining much.
Mark
Nico Kadel-Garcia
> I will, however, happily admit that I tend to be unusually lucky when I
> run new things (for example, I've been running kernel 2.6.24 for quite
> some time now), that even our servers at work are fairly lightly loaded
> (I try to overspec them to avoid future headaches), and that I can't
> claim to have measured any actual speed improvement from choosing 64-bit
> instead of 32-bit. So I may have dodged some problems without really
> gaining much.
From professional experience: 64-bit is wonderful for tools that have been
out long enough to be properly tested in 64-bit. I got involved in porting
Wacom tablet drivers to 64-bit SuSE some time ago, and it's possible to do
things like that, but I don't recommend it for people who expect things to
"just work", anymore than I recommend they try new combinations of high-end
components.
Mark T.B. Carroll
(snip)
> From professional experience: 64-bit is wonderful for tools that have been
> out long enough to be properly tested in 64-bit. I got involved in porting
> Wacom tablet drivers to 64-bit SuSE some time ago, and it's possible to do
> things like that, but I don't recommend it for people who expect things to
> "just work", anymore than I recommend they try new combinations of high-end
> components.
That's true - I do tend to shy away from the new and strange when it
comes to hardware I hope to use with Linux. That might help to explain
my luck.
Mark
Andrew Halliwell
> Where can I fetch an AMD64 kernel to play with? I could easily note the
> differences in performance if any.
If you want to play about with one to test performance, you're probably
better off downloading a generic kernel from kernel.org and compiling 2 to
test yourself, that way you know the only compile options that change are
the architecture (i686 and AMD64) so you have a good baseline to compare
them against.
--
| spi...@freenet.co.uk | |
| Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
| in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
| Computer Science | - Father Jack in "Father Ted" |
Hadron
> On Sun, 20 Apr 2008 20:37:44 +0100, Andrew Halliwell wrote:
>
>> Meat Plow <me...@petitmorte.net> wrote:
>>> Where can I fetch an AMD64 kernel to play with? I could easily note the
>>> differences in performance if any.
>>
>> If you want to play about with one to test performance, you're probably
>> better off downloading a generic kernel from kernel.org and compiling 2 to
>> test yourself, that way you know the only compile options that change are
>> the architecture (i686 and AMD64) so you have a good baseline to compare
>> them against.
>
> Thanks. I thought about that right after I hit the send button.
>
Or you could not bother and compare the config files that ship with the
bespoke debian kernels. You will find little difference.
You would be far more interested in "standard" kernel stability and
performance than some optimised mish mash assuming you want to
use it on your desktop.
Clearly if you have very specialised needs then the above might not be
so valid. I know that whenever I have compiled my own there is very,
very little difference in performance and one of the only times I would
consider it would be for very specialised HW situations where I know I
can leave out 90% of the default drivers.