My system has an AMD Phenom 9500 quad-core cpu;
but the Phenom cpu family is not one of the choices available
when trying to specify cpu-type during Slackware/Linux install.

make config/menuconfig shows other AMD cpu types as choices;
but, it defaults to assuming Pentium Pro instead.
(which I believe came before Pentium 2?)

Can I specify a different cpu-type, like one of the other AMD models or possibly just assume its compatible with something like Intel Pentium 4?

It seems like I would be under-utilizing my system's performance potential if I just settle for the default.

This would also apply to gcc's -mtune=<cpu-type> for programming.

For the time being, I am not trying to move to 64-bit Linux;
I just want 32-bit Linux to utilize my system's capabilities more.

I discovered that a new release of GCC now has compiler options available where you can specify both:

-mtune=amdfam10
and
-march=amdfam10

(Phenom cpu's are in the 16 or 0x10 hex family)

--> Older versions of GCC don't have it though

Will I have to wait for a new release of Slackware that includes the newer GCC?

Or, is there a way to compile a new kernel for this using older GCC?

As it would be better if the choice appears in make config/menuconfig.

Optimization for specific cpu won't help too much in performace

"Optimization for specific cpu won't help too much in performace"

??

If you had a truck with an 8 cylinder engine that was designed to run on 6 cylinders when you just use it for economical transportation (like a car), but it was meant to use all 8 cylinders when hauling a heavy load or towing a large trailer, wouldn't you be concerned if you could not get it to stop emulating a 6 cylinder?

use the amdfam10 flags just enable support for sse4a. but currently there is less (even sse3) applications support it.

If you do so, you may also make your programs more likely to crash.

When you compile kernel you can set the smp. The default number of processors is already set above 4.

Slackware 12.1 smp kernels should work for you automatically. The default vmlinuz points to vmlinuz-huge-smp-2.6.24.5-smp. I would make a more custom one if I were you but the huge does work for most people. These are probably set to i486 mode or i686 mode but these work fine for my amd4800 which is a dual core and both cores do work. Assuming I'm interpreting this right, I've looked at cpu load with kde performance monitor and it shows both cores being loaded.

"use the amdfam10 flags just enable support for sse4a. but currently there is less (even sse3) applications support it."

amdfam10 options are not available on the current/latest Slackware release,
and the version of GCC included with the latest Slackware release does not have those flags either.

>> FYI:
>> The benchmarking for my CPU was done on a Linux system;
>> so, logically, there should be a way to build a kernel for it with existing releases.

The latest release of GCC has "amdfam10" flags,
but that is newer than the GCC provided with the latest Slackware.

Ideally, a kernel build would use the -mtune=native and -march=native flags;
but, if mine is defaulting to Pentium Pro (i686), it will require a new release of Slackware for the kernel make's to utilize "amdfam10".

I'm sorry but aukuntin is right, using CFLAGS will give you very little if any performance benefit. For a slightly more noticeable benefit use 64-bit slamd64, I do and it's approximately 1 second faster at running some basic commands. If you were to optimize Slackware for your processor you would not even get 1 second, maybe a few nanoseconds. It depends a lot more on how the programs themselves are written. If they are written to use the new SEE* registers then you will get a more significant performance boost, and also if gcc is smart enough to know when to use them.

Why don't we all just settle for the 386 instruction set then?

Whats the point of having different cpu's available if they all just end up emulating some least common denominator?

Most self-proclaimed kernel building experts recommend specifying *your* cpu-type in the make config.

To reiterate my goal ...

--> I want Linux to recognize/utilize the hardware it is installed and running on.

(Added performance/functionality is just hopefully a side-effect of that goal.)

Hi,
We have already settled with the i386 instruction set for that family. You will always have the Intel based systems therefore the universality of Linux. You were given good advice but yet fail to see the point. If you want bleeding edge then by all means go for it. No ones stopping you from that but you.

BTW, emulation has nothing to do with the the code compatibility within a processor family. The backwards compatibility is the basis of a family instruction set.

As for the the statement about kernel experts then state who, where and what? Too general of a statement. You can always optimize 'current' families within the kernel's awareness. The kernel will catch up soon to the newer processors as they become available and when the 'kernel experts' work the code. That's the power of backwards compatibility.

Well, I have been leaning toward that conclusion ... that a future Slackware release will resolve this.

Considering that benchmarks of my system's cpu were done on/using Linux,
those doing the benchmarking had to successfully build a usable kernel;
meaning ... others must know how to configure it on existing Linux releases?

AMD Phenom cpu is relatively new as a "cpu-family".
but the model I have is one of the earliest cpu's in that family.
(been around for a while)

If not ... is there a recommended cpu-type for backward compatibility *other* than the minimum common denominator (Pentium Pro) that would be close to its own abilities?

---

Most responses so far are more opinionated about whether the goal posed by my questions are worth caring about.
I an *assuming* most people care enough about graphic performance to make sure they use the best drivers for them, or even upgrade hardware for improvements;
are issues about fine tuning kernels for your CPU so much less significant?

--> Linux should be configured and built on/for the CPU its going to run on.
What is wrong with trying to follow that concept?

Hi,

No one is telling you that you can't compile using a newer processor. You have to realize that it is is more than just the kernel that would have to be optimized. Applications will have to be updated along with libs, compiler, etc.

You would be better off running a 64 bit distribution and see how that would run for effect. Then you could or would start to optimize the kernel. Most popular applications are going to be 32 bit.

You don't need kernel to catch up to use multiprocessors. As I've said, the smp setting and smp kernels allow use of multiple processors including yours. They do this today.

You can compile your own kernel.
In Processor type and features:
Choose symmetric multi-processor support (smp).
Choose PC - compatible
Choose Opteron/Athlon64/Hammer/K8

Perhaps in future there might be some additional optimization for phenom but the selection above should be a little better than i486 or i686.

Because most of the package that I use are built by others and they are built for i386, i486, or i686, and because I MIGHT build packages to share (watch out world), I've chosen to build last kernel to i686. I have built kernels before for the athlon64. I never noticed any real difference but I wasn't doing benchmarks.

You will make you own choice. Maybe you'll post some benchmarks to show how some kernel setting causes a difference.

Hi,

The OP wants to have a processor specific kernel. If the family is not there then no way. We were not speaking in the manner you are. He was comparing the i386 and having to run on his new current processor. His wants to use the current instruction set to his advantage for his processor. He would have to wait to get the newest processor for the kernel if the instruction set was not yet supported.

The gain would not be that much!

You seem to agree with what we are saying.