Kernel Optimization and RH 6

Kernel Optimization and RH 6

[Rolando López]

Are the lines below the best option to compile a 2.2.x kernel with egcs running
on a Pentium II?

-O6 -mpentiumpro -march=pentiumpro -malign-function=2
-malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
-fstrength-reduce

Background

We have recently installed RedHat 6 on a PowerEdge 4300, PII 350Mhz with 256MB
of RAM.  RedHat 6 determines the type of processor and installs the compiled
kernel accordingly.  This kernel has been compiled with the "best" performance
optimizations depending on the hardware. 

As a non-scientific measure of this kernel performance, at boot time, the
RAID 5 routines reached 850MB/s.  This measure can be seen after booting in /var/log/messages

After that, we updated the kernel to version 2.2.7, but we obtained only 835MB/s
in the same measure.

These are the options used and the compiler version:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

We modify /usr/src/linux/Makefile like this:

HOSTCC = egcs
HOSTCFLAGS = -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer
CC = $(CROSS_COMPILE)egcs -D__KERNEL__ -I$(HPATH)


And /usr/src/linux/arch/i386 as the following:

CFLAGS_NSR := -fstrength-reduce
ifdef CONFIG_M686
CFLAGS := $(CFLAGS) -mpentiumpro -march=pentiumpro -malign-loops=2
-malign-jumps=2 -malign-functions=2 -DCPU=686
endif

The machine is used as transparent proxy server with squid 2.2.stable3 (compiled
with the same options)

We didn't have any trouble at compilation time nor we had stability problems
with egcs.  Squid is reaching the 50% Hit Ratio but is using too much CPU time, 
around 27% with 17% of system time and 10% of user time.

I understand that optimizing the kernel is not what best improves performance, but
there is nothing else we could do to the PowerEdge 4300 with our current budget, and
given that the options used to compile RedHat 6 achieved a better throughput
(850 versus 835) and that squid is using too much system time, 
maybe there should be something that could be done to recompile the
kernel and squid and obtain some kind of improvement.

I'll appreciate your advice on this.

Regards,

Rolando

Re: Kernel Optimization and RH 6

[Arvind Sankar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Mon, Jul 12, 1999 at 03:16:22PM -0600, Rolando López wrote:
> Are the lines below the best option to compile a 2.2.x kernel with egcs running
> on a Pentium II?
> 
> -O6 -mpentiumpro -march=pentiumpro -malign-function=2
> -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
> -fstrength-reduce

add -fno-strict-aliasing for correctness.

-- arvind

Re: Kernel Optimization and RH 6

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Rolando López wrote:
> Are the lines below the best option to compile a 2.2.x kernel with egcs running
> on a Pentium II?
> 
> -O6 -mpentiumpro -march=pentiumpro -malign-function=2
> -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
> -fstrength-reduce

You might try -mregparm=1 though you have to modify the kernel a little
in order to get it to run :-)

(No I don't have patches).

-- Jamie

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

  In message < 19990713192833.E24040@pcep-jamie.cern.ch >you write:
  > Rolando López wrote:
  > > Are the lines below the best option to compile a 2.2.x kernel with egcs r
  > unning
  > > on a Pentium II?
  > > 
  > > -O6 -mpentiumpro -march=pentiumpro -malign-function=2
  > > -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
  > > -fstrength-reduce
  > 
  > You might try -mregparm=1 though you have to modify the kernel a little
  > in order to get it to run :-)
I would recommend against this.  There are situations where it will cause the
compiler to generate incorrect code.

jeff

Re: Kernel Optimization and RH 6

[Jamie Lokier]

Jeffrey A Law wrote:
>   > You might try -mregparm=1 though you have to modify the kernel a little
>   > in order to get it to run :-)
> I would recommend against this.  There are situations where it will cause the
> compiler to generate incorrect code.

Maybe, but I've compiled some big C++ projects and had no problems.
And the code was definitely smaller, if not faster (I didn't measure speed).
Maybe -mregparm=2 or 3 is worse.

Do you have a testcase?

thanks,
-- Jamie

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

  In message < 19990713193821.G24040@pcep-jamie.cern.ch >you write:
  > Maybe, but I've compiled some big C++ projects and had no problems.
  > And the code was definitely smaller, if not faster (I didn't measure speed)
  > Maybe -mregparm=2 or 3 is worse.
I don't have a testcase handy.  But it definitely has problems.

jeff

Re: Kernel Optimization and RH 6

[Kamil Iskra]

On Tue, 13 Jul 1999, Jeffrey A Law wrote:

>   > You might try -mregparm=1 though you have to modify the kernel a little
>   > in order to get it to run :-)
> I would recommend against this.  There are situations where it will cause the
> compiler to generate incorrect code.

Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
supposed to fix these code generation errors?

Kamil Iskra

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9907202259400.1790-100000@jinks.home >you write:
  > Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
  > supposed to fix these code generation errors?
It fixed a lot of these issues, but certainly not all that apply to
-mregparm.

It's less likely to screw up, but -mregparm certainly still has problems.

jeff

Re: Kernel Optimization and RH 6

[Bernd Schmidt]

>   > Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
>   > supposed to fix these code generation errors?
> It fixed a lot of these issues, but certainly not all that apply to
> -mregparm.
> 
> It's less likely to screw up, but -mregparm certainly still has problems.

I don't think it actually has any invalid code generation problems anymore,
but it definitely does cause compiler aborts in some situations.

Bernd

Re: Kernel Optimization and RH 6

[Arvind Sankar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Mon, Jul 12, 1999 at 03:16:22PM -0600, Rolando López wrote:
> Are the lines below the best option to compile a 2.2.x kernel with egcs running
> on a Pentium II?
> 
> -O6 -mpentiumpro -march=pentiumpro -malign-function=2
> -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
> -fstrength-reduce

add -fno-strict-aliasing for correctness.

-- arvind

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

  In message < 19990713192833.E24040@pcep-jamie.cern.ch >you write:
  > Rolando López wrote:
  > > Are the lines below the best option to compile a 2.2.x kernel with egcs r
  > unning
  > > on a Pentium II?
  > > 
  > > -O6 -mpentiumpro -march=pentiumpro -malign-function=2
  > > -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
  > > -fstrength-reduce
  > 
  > You might try -mregparm=1 though you have to modify the kernel a little
  > in order to get it to run :-)
I would recommend against this.  There are situations where it will cause the
compiler to generate incorrect code.

jeff

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

  In message < 19990713193821.G24040@pcep-jamie.cern.ch >you write:
  > Maybe, but I've compiled some big C++ projects and had no problems.
  > And the code was definitely smaller, if not faster (I didn't measure speed)
  > Maybe -mregparm=2 or 3 is worse.
I don't have a testcase handy.  But it definitely has problems.

jeff

Re: Kernel Optimization and RH 6

[Kamil Iskra]

On Tue, 13 Jul 1999, Jeffrey A Law wrote:

>   > You might try -mregparm=1 though you have to modify the kernel a little
>   > in order to get it to run :-)
> I would recommend against this.  There are situations where it will cause the
> compiler to generate incorrect code.

Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
supposed to fix these code generation errors?

Kamil Iskra

Re: Kernel Optimization and RH 6

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Rolando López wrote:
> Are the lines below the best option to compile a 2.2.x kernel with egcs running
> on a Pentium II?
> 
> -O6 -mpentiumpro -march=pentiumpro -malign-function=2
> -malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
> -fstrength-reduce

You might try -mregparm=1 though you have to modify the kernel a little
in order to get it to run :-)

(No I don't have patches).

-- Jamie

Re: Kernel Optimization and RH 6

[Bernd Schmidt]

>   > Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
>   > supposed to fix these code generation errors?
> It fixed a lot of these issues, but certainly not all that apply to
> -mregparm.
> 
> It's less likely to screw up, but -mregparm certainly still has problems.

I don't think it actually has any invalid code generation problems anymore,
but it definitely does cause compiler aborts in some situations.

Bernd

Re: Kernel Optimization and RH 6

[Jamie Lokier]

Jeffrey A Law wrote:
>   > You might try -mregparm=1 though you have to modify the kernel a little
>   > in order to get it to run :-)
> I would recommend against this.  There are situations where it will cause the
> compiler to generate incorrect code.

Maybe, but I've compiled some big C++ projects and had no problems.
And the code was definitely smaller, if not faster (I didn't measure speed).
Maybe -mregparm=2 or 3 is worse.

Do you have a testcase?

thanks,
-- Jamie

Kernel Optimization and RH 6

[Rolando López]

Are the lines below the best option to compile a 2.2.x kernel with egcs running
on a Pentium II?

-O6 -mpentiumpro -march=pentiumpro -malign-function=2
-malign-jumps=2 -malign-loops=2 -fomit-frame-pointer
-fstrength-reduce

Background

We have recently installed RedHat 6 on a PowerEdge 4300, PII 350Mhz with 256MB
of RAM.  RedHat 6 determines the type of processor and installs the compiled
kernel accordingly.  This kernel has been compiled with the "best" performance
optimizations depending on the hardware. 

As a non-scientific measure of this kernel performance, at boot time, the
RAID 5 routines reached 850MB/s.  This measure can be seen after booting in /var/log/messages

After that, we updated the kernel to version 2.2.7, but we obtained only 835MB/s
in the same measure.

These are the options used and the compiler version:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

We modify /usr/src/linux/Makefile like this:

HOSTCC = egcs
HOSTCFLAGS = -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer
CC = $(CROSS_COMPILE)egcs -D__KERNEL__ -I$(HPATH)


And /usr/src/linux/arch/i386 as the following:

CFLAGS_NSR := -fstrength-reduce
ifdef CONFIG_M686
CFLAGS := $(CFLAGS) -mpentiumpro -march=pentiumpro -malign-loops=2
-malign-jumps=2 -malign-functions=2 -DCPU=686
endif

The machine is used as transparent proxy server with squid 2.2.stable3 (compiled
with the same options)

We didn't have any trouble at compilation time nor we had stability problems
with egcs.  Squid is reaching the 50% Hit Ratio but is using too much CPU time, 
around 27% with 17% of system time and 10% of user time.

I understand that optimizing the kernel is not what best improves performance, but
there is nothing else we could do to the PowerEdge 4300 with our current budget, and
given that the options used to compile RedHat 6 achieved a better throughput
(850 versus 835) and that squid is using too much system time, 
maybe there should be something that could be done to recompile the
kernel and squid and obtain some kind of improvement.

I'll appreciate your advice on this.

Regards,

Rolando

Re: Kernel Optimization and RH 6

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9907202259400.1790-100000@jinks.home >you write:
  > Sorry to butt in, but wasn't the reworked reload pass (by Bernd Schmidt)
  > supposed to fix these code generation errors?
It fixed a lot of these issues, but certainly not all that apply to
-mregparm.

It's less likely to screw up, but -mregparm certainly still has problems.

jeff