| View previous topic :: View next topic |
| Author |
Message |
Helmut Hullen
Guest
|
 Posted: Tue Nov 18, 2008 5:13 pm Post subject: 64-bit kernel, 32-bit software |
 |
|
Hallo,
I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
Does it reach to only recompile the kernel (I compile my own kernel, no
need for sound or video etc.) and then use the old 32-bit software?
Must I use some 64-bit-software too (especially "module-init-tools")?
I wouldn't like to use parallel libraries for 32 and 64 bit ...
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me". |
|
| |
|
 Back to top |
Petri Kaukasoina
Guest
|
| Posted: Tue Nov 18, 2008 5:13 pm Post subject: Re: 64-bit kernel, 32-bit software |
|
|
Helmut Hullen <helmut@hullen.de> wrote:
| Quote: | Does it reach to only recompile the kernel (I compile my own kernel, no
need for sound or video etc.) and then use the old 32-bit software?
|
Yes. Just use CONFIG_IA32_EMULATION=y in your .config.
| Quote: | Must I use some 64-bit-software too (especially "module-init-tools")?
|
No. |
|
| |
|
| Back to top |
Murat D. Kadirov
Guest
|
| Posted: Tue Nov 18, 2008 5:13 pm Post subject: Re: 64-bit kernel, 32-bit software |
|
|
On Tue, 18 Nov 2008 12:13:00 +0100, Helmut Hullen wrote:
| Quote: | Hallo,
I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
|
You may use PAE |
|
| |
|
| Back to top |
Helmut Hullen
Guest
|
| Posted: Tue Nov 18, 2008 7:45 pm Post subject: Re: 64-bit kernel, 32-bit software |
|
|
Hallo, Murat,
Du meintest am 18.11.08:
| Quote: | I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
You may use PAE
|
Do you mean
http://en.wikipedia.org/wiki/Physical_Address_Extension
Maybe it helps in this special case.
But (I didn't mention it before) I guess that I have to change "in the
long run" completely to 64-bit, and only changing the kernel might be
the first step.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me". |
|
| |
|
| Back to top |
Nikos Chantziaras
Guest
|
| Posted: Tue Nov 18, 2008 10:58 pm Post subject: Re: 64-bit kernel, 32-bit software |
|
|
Helmut Hullen wrote:
| Quote: | Hallo, Murat,
Du meintest am 18.11.08:
I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
You may use PAE
Do you mean
http://en.wikipedia.org/wiki/Physical_Address_Extension
Maybe it helps in this special case.
But (I didn't mention it before) I guess that I have to change "in the
long run" completely to 64-bit, and only changing the kernel might be
the first step.
|
If you load a 64-bit kernel on a system that only has 32-bit support
libraries, it will hang. |
|
| |
|
| Back to top |
Floyd L. Davidson
Guest
|
| Posted: Wed Nov 19, 2008 1:25 am Post subject: Re: 64-bit kernel, 32-bit software |
|
|
helmut@hullen.de (Helmut Hullen) wrote:
| Quote: | Hallo,
I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
|
You'll want to verify precisely what the needs are,
because there are multiple issues that can easily be
confused. A requirement for more than 4 Gb of system
RAM because there are multiple processes and the system
uses slow disk space for virtual memory is one thing
(which more RAM can solve). A requirement for single
processes to have more than 4 Gb of virtual address
space is another thing (which a 64-bit system can
solve).
You can find, with relative easy, motherboards and CPU's
that will handle more than 4 Gb of RAM and still just
run 32-bit applications (where each process is limited
to a maximum of 4 Gb of address space). Such a system
works well to handle a heavy load with multiple users,
all of whom get real RAM without swapping to disk space.
The reason to move to a 64-bit system is to allow a
larger address space per process. Also note that it
essentially doubles the RAM requirements to get exactly
the same effect. Hence, if you are bumping into the 4
Gb address space limit per process, when you move to a
64-bit system you'll need more than 8 Gb to see
improvement.
| Quote: | Does it reach to only recompile the kernel (I compile my own kernel, no
need for sound or video etc.) and then use the old 32-bit software?
Must I use some 64-bit-software too (especially "module-init-tools")?
|
If you run a 64-bit kernel, you need a 64-bit based
system (libraries, etc).
| Quote: | I wouldn't like to use parallel libraries for 32 and 64 bit ...
|
If you have a 64-bit based system and want to run 32-bit
applications, every library used by those applications
must be available in a 32-bit version. (This is one of
the complications that makes it worth avoiding a 64-bit
system if you do not need more than 4 Gb of address
space per process.)
More than 4 Gb of RAM can of course be very useful on a
32-bit system. PAE is built into the more recent
kernels (at compile time you have the option to choose
less than 1GB, less than 4Gb, or more than 4GB.
However that does not change the amount of virtual
address space available per process! Hence, with a
32-bit kernel you can have 4 processors each running a
program with 4 GB of address space if you have 16GB of
RAM installed. But you can't have 1 processor running 1
program with 16Gb of virtual address space. That is
where the potential need for using a 64-bit kernel comes
in. If you do want to run processes that need more than
4 Gb of virtual memory, then you do need a 64-bit
kernel.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com |
|
| |
|
| Back to top |
Jim Diamond
Guest
|
| Posted: Wed Nov 19, 2008 1:57 am Post subject: Re: 64-bit kernel, 32-bit software |
|
|
On 2008-11-18 at 15:25 AST, Floyd L. Davidson <floyd@apaflo.com> wrote:
| Quote: | helmut@hullen.de (Helmut Hullen) wrote:
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
You'll want to verify precisely what the needs are,
because there are multiple issues that can easily be
confused. A requirement for more than 4 Gb of system
RAM because there are multiple processes and the system
uses slow disk space for virtual memory is one thing
(which more RAM can solve). A requirement for single
processes to have more than 4 Gb of virtual address
space is another thing (which a 64-bit system can
solve).
You can find, with relative easy, motherboards and CPU's
that will handle more than 4 Gb of RAM and still just
run 32-bit applications (where each process is limited
to a maximum of 4 Gb of address space). Such a system
works well to handle a heavy load with multiple users,
all of whom get real RAM without swapping to disk space.
|
So far so good.
| Quote: | The reason to move to a 64-bit system is to allow a
larger address space per process. Also note that it
essentially doubles the RAM requirements to get exactly
the same effect. Hence, if you are bumping into the 4
Gb address space limit per process, when you move to a
64-bit system you'll need more than 8 Gb to see
improvement.
|
Eh? What makes you say that? Just because I am using a 64-bit
machine doesn't mean that all my instructions and data values
instantly double in size. An array of 1,000,000 32-bit ints is still
an array of 1,000,000 32-bit ints on a 64-bit machine.
| Quote: | I wouldn't like to use parallel libraries for 32 and 64 bit ...
If you have a 64-bit based system and want to run 32-bit
applications, every library used by those applications
must be available in a 32-bit version. (This is one of
the complications that makes it worth avoiding a 64-bit
system if you do not need more than 4 Gb of address
space per process.)
|
Slamd64 comes with both 32-bit libraries and 64-bit libraries, at the
cost of some disk space. Are you (the OP) worried about the disk
space, or the effort of creating/maintaining them?
I've played with Slamd64 a bit, and found out that compiling some
packages is a bit more of a trick on Slamd64 than slackware (12.1 in
both cases). For example, some slackbuilds compile for 64-bit quite
easily, others don't. I didn't play around with things long enough to
find out what was going on, but the fact that I could fall back to a
32-bit library and use the slackware package was actually a nice thing.
Cheers.
Jim |
|
| |
|
| Back to top |
Helmut Hullen
Guest
|
| Posted: Wed Nov 19, 2008 2:17 am Post subject: Re: 64-bit kernel, 32-bit software |
|
|
Hallo, Floyd,
Du meintest am 18.11.08:
| Quote: | I'm maintainig a schoolserver distribution based on slackware
(slackware-current). More and more collegues wish to use more than 4
GByte RAM, newer servers have 64-bit-CPUs.
You'll want to verify precisely what the needs are,
because there are multiple issues that can easily be
confused.
|
[...]
That's at least hard, that may be impossible.
Some collegues use the system as a terminalserver which serves about 50
clients.
Some use it mostly for data base applications.
Pure number crunching is seldom.
[...]
| Quote: | The reason to move to a 64-bit system is to allow a
larger address space per process.
|
The standard reason is "my hardware dealer only has 64-bit systems with
more than 4 GByte RAM". Strange ...
But nevertheless: thank you (and all the other writers) for your mail!
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me". |
|
| |
|
| Back to top |
Henrik Carlqvist
Guest
|
| Posted: Wed Nov 19, 2008 4:14 am Post subject: Re: 64-bit kernel, 32-bit software |
|
|
Jim Diamond <Jim.Diamond@nospam.AcadiaU.ca> wrote:
| Quote: | I've played with Slamd64 a bit, and found out that compiling some
packages is a bit more of a trick on Slamd64 than slackware (12.1 in
both cases). For example, some slackbuilds compile for 64-bit quite
easily, others don't. I didn't play around with things long enough to
find out what was going on,
|
In my experience when some software doesn't compile out of the box on
slamd64 it is usually because some library need to be compiled with the
-fPIC switch.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost |
|
| |
|
| Back to top |
Jim Diamond
Guest
|
| Posted: Wed Nov 19, 2008 5:37 am Post subject: Re: 64-bit kernel, 32-bit software |
|
|
On 2008-11-18 at 18:14 AST, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
| Quote: | Jim Diamond <Jim.Diamond@nospam.AcadiaU.ca> wrote:
I've played with Slamd64 a bit, and found out that compiling some
packages is a bit more of a trick on Slamd64 than slackware (12.1 in
both cases). For example, some slackbuilds compile for 64-bit quite
easily, others don't. I didn't play around with things long enough to
find out what was going on,
In my experience when some software doesn't compile out of the box on
slamd64 it is usually because some library need to be compiled with the
-fPIC switch.
|
Yeah, I didn't get into the details (mea culpa), but I have used that
on all the slackbuilds that I tried under Slamd64. In fact, some
benevolent soul (Carlos Corbacho, according to the comment in the
file) created a program (sbo64.py) which tries to automagically
convert a (32-bit) slackbuild script to something which will work
under Slamd64. In most of the cases it worked for me, but in a few it
didn't.
Cheers.
Jim |
|
| |
|
| Back to top |
|
