I just installed Slackware 12.2 onto my new machine, and it's a beauty, but I want to get the MAX that I can out of this setup. For some reason it's not utilizing all of my RAM, only half of it. I have 4 sticks of Patriot Viper 1GB DDR3 2000 installed on my mobo, which does indeed have a 64 bit processor (AMD Phenom II X4 955 Black Edition).

As far as I've read this setup should be using all of the RAM, correct? Linux 2.6.27.7 should be more than able to handle 4 gig.

I have also looked in the BIOS to make sure there isn't a limitation there either. Doesn't seem to be any settings dealing with how much RAM is used.

Anyone have any ideas? Is there something I missed?

How do you know that it is not using all of your RAM?

Is it recognizing that you have 4 gigs, and just not using it? How are you determining this?

--jrtayloriv

With a 32bit OS you will only be able to use about 3.1gig (roughly) unless you switch to a PAE kernel. If you could post the results of 'free' it might give us some ideas. Other issues that can reduce the amount of ram the OS can use (dropping below 3.1gig) include cards (usually video) that used system memory rather than on card memory.

Nope, none of those issues. Unless the Linux kernel is locked at 32 bit even if you install it using a 64 bit CPU. which mine definitely is. I thought it automatically configures it? and my video cards have 512mb of their own memory each (it's a crossfire setup btw). so that's definitely not the problem.

it shows up as 2.7GB, not 3.1, so I don't think it got setup on 32 bit some way. as for how I know how much it's using (not using, I mean how much is available) I just saw it in KInfoCenter.

here's the results of free:

it says it's a total of roughly 2.7 GB, as I stated earlier.

But during POST it states I have over 4GB. so I know it isn't a BIOS issue for sure. it's OS related.

Been a while since I played with slack so I had to check to be sure. Until V13.0 Slackware(proper) is 32bit only, obviously a 32bit OS will run on a 64bit cpu. That still leaves about .3gb unaccounted for.


http://www.slackware.com/

Does slack current support 64bit at all? Or is there anyway to get slackware to?

As for the unaccounted .3gb, there may be something in the bios, I'll check for that.

Nevermind, I just read the page on the slackware site. Thanks. Is there anything else I should know about Slackware64-current? As far as I can tell this is my solution, correct?

Wait, can I actually download it yet? I don't see an ISO listed for it. I'm not sure exactly how the -current part fits into this...

Forgive my ignorance, lol. I'm learning though.

Hi,

Slackware 13.0 RC2 x86_64 is the -current for x86_64. You can download using 'Alien_Bob's-script -mirror-slackware-current.sh'.

You can edit the script to select your media type for the ISO, plus the mirror to use. The script is well documented to allow you move around and configure. You can pass parameters to the script, these too are documented within the script.

The above link and others available from 'Slackware-Links'. More than just Slackware® links!

You should post the memory map that the bios hands to Linux. If the log hasn't overflowed since the last boot up, you can get that with
Look for something that looks similar to this:
From that we can determine whether the missing memory is a BIOS/Hardware issue or a Linux kernel issue.

The BIOS and hardware determine how much memory (usually about 3.25GB but maybe as little as 2.7) is in the first 4GB of address space and they determine whether the rest of memory is remapped elsewhere that Linux can use it or whether the rest is lost.

If you have a 32 bit non PAE Linux kernel, you can only use the part of ram that is in the first 4GB of address space. If you have 32 bit PAE or 64 bit you can use all the ram that the bios makes available.

This is a misunderstanding. There is a choice of kernels, compiled with various conditions (32 bit, PAE, 64 bit, for the trivial examples) and when a kernel is installed that sets limits to the system.

And, its not just the kernel, libraries and apps have to be compiled appropriately, but there are are some arrangements for backward compatability, so that with the appropriate libraries it is possible to run 32 bit apps under a 64 bit system.

For systems which have 32 and 64 bit versions, usually sizes dictate separate DVDs for the 32 and 64 bit systems; otherwise it would have been convenient to have an install script that detects 32/64 and behaves appropriately (which would still be to ask, in the case of 64 bit processors). So, you have to select the correct install CD/DVD/image and if you have selected a 32 bit one, it will just install that regardless of whether the system could run a 64 bit system.

As I understand the situation with slackware, the 'official' 64 bit version is not fully available. You could

• accept the 32 bit version
• wait for the official 64 bit version
• use the not-quite-officially-available-yet forthcoming 64 bit version
• use a derivative version which is already 64 bit (bluewhite, slamd64, others?)

I'm not sure about the situation with slackware and the PAE kernel. For some people this is a worthwhile halfway house. It is still a 32 bit system, but by an arrangement akin to paging it makes use of more memory, but doesn't increase the memory addressing range available to an individual application. You can see how this would not be the ideal solution for someone who has a box on which they only want to run a single copy of Oracle with a massive data requirement...

I'm not either. But I expect you would need to recompile the kernel to get PAE and I expect recompiling the kernel is a well supported/documented operation (as opposed to many distributions that expect all but advanced users will download precompiled kernels via the package manager).

If you already have 32 bit non PAE installed, the big advantage of 32 bit PAE over 64 bit is:
1) You can replace just the kernel and not change the rest of the install.
2) You can keep the old kernel and select between them at boot time, either initially to test whether you really like the change, or later for a variety of less likely but plausible purposes.
Switching to 64 bit from 32 bit is much more disruptive than switching to PAE from non PAE.


Linux always uses paging. PAE uses a paging data structure that is different from the original paging data structure for 32 bit (PAE is more similar to the paging data structure for 64 bit).

Correct. PAE increases the physical address space to 64GB but does not increase the virtual address space (3GB per process).

I don't know how Oracle does its file I/O. If it uses ordinary file I/O or simple dynamic file mapping then 32 bit PAE might be ideal for a single copy of Oracle on a system with 4GB of ram. It is ideal in such applications for a significant fraction of ram to be in cache rather than the working set of the process at any given moment, and 32 bit PAE certainly allows caching on behalf of a single process to use as much ram as available. For a database, 32 bit mode may result in fewer L2 and TLB misses in both the process itself and the kernel.

Oracle might have a file mapping system that makes good use of extra (above 3GB) virtual address space, in which case 32 bit PAE would not be as good as 64 bit. I don't know those internal details of Oracle.

To make that more clear; there are two meanings to paging; the type hidden inside virtual memory management is done by default in desktop and server linuxes (but not necessarily embedded linuxes, which are often run on processors without an mmu) and I should have made it clear that I was referring to ram paging (and not swapping to disk) which was done on systems like Z80s to get the memory space above 64k (and, back then, 64k was often all people could afford, which tells you a lot) by having several pages of memory that were adressed by a simple latch arrangement so that by writing the appropriate byte to the latch, you got that page. Often 32k was paged and the rest of the space unpaged...these days you can't do anything in 32M never mind 32k.

These days the page register facility is built-in to the memory controller, so with an appropriate chipset, you don't have to add hardware to do this.


Its preference is for its own optimised system, but it will use whatever it is given. This is not the point, though. The point was if an application, a single application and not a collection of threads, needs a large resident set, then PAE is not going to be that helpful. File I/O is quite another subject.

A single very large database is an example of the kind of thing that can run into this trouble. There are many more typical server applications where either the application isn't as monolithic or there are several medium-sized applications where PAE is of more obvious application.

I couldn't find anything that looked like that in the results returned by dmesg. I went up and down the pages several times to make sure.


I saw something about AMD64 being configured during the installation, so i just assumed it was going to use 64-bit. But that was probably just for it to run 32-bit on the 64-bit CPU. That "compatibility" you were talking about. Thanks for clearing that up.

How similar is Slamd64 to regular slackware? or what's the difference to the slackware64-current? I know the inherent risks of using the in-development "-current" release. But I have nothing important riding on this installation or any that I replace it with. I mean I don't care much if it's unstable and crashes a lot or anything. This is pretty much a test, which I will use long-term on the condition it performs well enough.

My current decision is to use either Slamd64 or the incomplete slack64. Can I have an elaboration on the pros and cons of each?

What I'm aiming for is to use the max potential of this machine, I don't care so much about stability if it has to be sacrificed for performance. What I mean is, I would chose performance & capabilities over stability & security.

If that is your set of priorities, I'd grab the slackware 64 bit tree and do it now. You know that there are going to be bugfixes, they might even be along soon, but that's not much of a concern, just be sure that you keep updated.

Slack is pretty stable/conservative, so given your priorities, and tolerance of a few rough edges in the interests of performance, I think you'll be fine.

Don't think, by the way that 64 bits is going to unleash a massive extra burst of performance; it isn't. When you need the ram that is currently inaccesible, there will be a rather clear gain, but the rest of the time, it is more likely to be the kind of change that you would need a benchmarking program to detect.

At some point that log overflows. I don't know how to get that info after the log has overflowed other than reboot the whole system and check dmesg fairly soon after boot.

Maybe some other expert here knows how to get that at any time (or knows if that map is somewhere else in Slackware).

That sounds right.

No. That doesn't make sense.

You should check whether your kernel is x86 or x86_64. The uname -a command is the best way to find out. For 64 bit it should say x86_64 three times. For 32 bit it will not say x86_64 even once. I don't think it would say AMD64 in the output of uname, but if it did that is the same as x86_64.

If the problem is in the bios or motherboard, switching kernels won't help. Up to 16GB, 32 bit PAE and 64 bit are both equally able to use the ram the BIOS makes available and equally unable to use ram that the bios does not make available. (Above 16GB, 32 bit PAE has issues with kernel virtual memory and above 64GB PAE can't address at all).

Yes, that's what I was counting on. In fact, that reminds me to ask: what's a good benchmarking utility? Preferably I'd like to test CPU processing power, as well as RAM allocation ability and speed, and GPU processing power. I have a dual GPU setup with two ATI Radeon HD 4850's using CrossFireX. I was surprised how well ATI/AMD supports Linux, the driver was right on the CD that came with it. They even have Tux right on the front of the box. It's always nice to see things like that.

Anyway, here is what uname told me:

Linux 2.6.27.7-smp #2 SMP Thu Nov 20 22:32:43 CST 2008 i686 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux

I am positive that the BIOS and mobo support everything, it's how I intended it when I ordered and built the machine. But I'm pretty sure I still need Slackware64-current. I've got an ISO burned to DVD now and I'm going to go ahead and install it on a new partition.

I'll let you all know how it goes.