lkml.org 
[lkml]   [2003]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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]
    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:0.023 / U:121.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site