Messages in this thread | | | Date | Fri, 24 Oct 2003 01:05:42 +0200 | From | "J.A. Magallon" <> | Subject | Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture |
| |
On 10.22, Joseph D. Wagner wrote: > Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under > processor type when doing a 'make xconfig', but those selections do not > translate into the appropriate -mcpu and -march flags. > > While the kernel on x86 architecture can be optimized in terms of generic > processor specifications (i.e. i386, i486, i586, i686), the kernel can't be > optimized beyond a i686. > > If you select Pentium III, the -march flag is set to i686. > If you select Pentium 4, the -march flag is set to i686. > If you select Athlon 4, the -march flag is set to i686. > If you select Athlon XP, the -march flag is set to i686. > > It should be that... > > If you select Pentium III, the -march flag is set to pentium3. > If you select Pentium 4, the -march flag is set to pentium4. > If you select Athlon 4, the -march flag is set to athlon-4. > If you select Athlon XP, the -march flag is set to athlon-xp. > > I don't want to have to hand edit the makefiles just to optimize my kernel. > I think this change is simple enough to do, and would allow kernel > developers the option of processor-specific optimizations in the future. > > TIA. > > Joseph D. Wagner
I have sent the attached patches sometimes to the list/Marcelo, and they have been rejected to the moment because: - gcc can spit some new instructions, reorganize code and other things when you jump from i686 to pentium3, for example. - There can be bugs both in gcc and in the kernel that can be triggered by >i686 optimizations/code. - This is not safe for a stable kernel, it was done in 2.5, bugs appeared, were corrected, and so on, 'cause this was a development kernel.
BTW, I use this regularly, and have not found any bugs, but I admit it is unsafe. I also advocate for a pII split (I use a dual PII ;). There are some other specific code that could be used in the kernel, for example mb() and so on can be implemented with {m,s,l}fence in p3/p4 processors, instead of the old 'lock; insn' (attached also).
-- J.A. Magallon <jamagallon()able!es> \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.23-pre7-jam2 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)) [unhandled content-type:application/x-bzip]
| |