unit-at-a-time...

unit-at-a-time...

[Paweł Sikora]

Hi,

/i386/Makefile:# Disable unit-at-a-time mode, it makes gcc use a lot morestack
/i386/Makefile:CFLAGS += $(call cc-option,-fno-unit-at-a-time)

/x86_64/Makefile:# -funit-at-a-time shrinks the kernel .text considerably
/x86_64/Makefile:CFLAGS += $(call cc-option,-funit-at-a-time)

Which solution is correct?

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

                           #define say(x) lie(x)

Re: unit-at-a-time...

[Mikael Pettersson]

On Sun, 31 Oct 2004 15:57:00 +0100, pluto@pld-linux.org wrote:
>/i386/Makefile:# Disable unit-at-a-time mode, it makes gcc use a lot morestack
>/i386/Makefile:CFLAGS += $(call cc-option,-fno-unit-at-a-time)
>
>/x86_64/Makefile:# -funit-at-a-time shrinks the kernel .text considerably
>/x86_64/Makefile:CFLAGS += $(call cc-option,-funit-at-a-time)
>
>Which solution is correct?

Disabling unit-at-a-time for i386 is definitely correct.
I've personally observed horrible runtime corruption bugs
in early 2.6 kernels when they were compiled with gcc-3.4
without the -fno-unit-at-a-time fix.

x86-64 is a different architecture. It's possible its larger
number of registers reduces spills enough that gcc's failure
to merge stack slots doesn't matter.

/Mikael

Re: unit-at-a-time...

[Jan Engelhardt]

>>/i386/Makefile:# Disable unit-at-a-time mode, it makes gcc use a lot morestack
>>/i386/Makefile:CFLAGS += $(call cc-option,-fno-unit-at-a-time)

Once I wanted to find out why -finline-functions still did not inline my
funcitons I tagged as "inline".. so I went flag by flag and finally came to the
point where -funit-at-a-time did the actual inlining. So it's like "make my .o
files bigger".

For x86_32 at least.



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: unit-at-a-time...

[Roland Dreier]

By the way, does anyone know if Richard Henderson's work in gcc 4.0
(http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00333.html) on laying
out stack variables means that -funit-at-a-time will be safe to use
again for the kernel?

Thanks,
  Roland

Re: unit-at-a-time...

[Arjan van de Ven]

On Sun, 2004-10-31 at 11:05 -0800, Roland Dreier wrote:
> By the way, does anyone know if Richard Henderson's work in gcc 4.0
> (http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00333.html) on laying
> out stack variables means that -funit-at-a-time will be safe to use
> again for the kernel?

unfortunately that's only half the task. It takes care of explicit
variables in inlines, but not about spilled variables, which is the
problem on x86 due to the lack of general purpose registers..
(and which is why x86-64 can use unit-at-a-time just fine)

Re: unit-at-a-time...

[Andi Kleen]

Mikael Pettersson <mikpe@csd.uu.se> writes:

> On Sun, 31 Oct 2004 15:57:00 +0100, pluto@pld-linux.org wrote:
> >/i386/Makefile:# Disable unit-at-a-time mode, it makes gcc use a lot morestack
> >/i386/Makefile:CFLAGS += $(call cc-option,-fno-unit-at-a-time)
> >
> >/x86_64/Makefile:# -funit-at-a-time shrinks the kernel .text considerably
> >/x86_64/Makefile:CFLAGS += $(call cc-option,-funit-at-a-time)
> >
> >Which solution is correct?

It shrinks the .text on i386 considerably too. One reason
is that it automatically enables regparms for static functions.
With global CONFIG_REGPARM the shrink is a bit less, but still
noticeable.

One drawback is that oopses are harder to read because
of the more aggressive inlining, but it's not too bad.

> 
> Disabling unit-at-a-time for i386 is definitely correct.
> I've personally observed horrible runtime corruption bugs
> in early 2.6 kernels when they were compiled with gcc-3.4
> without the -fno-unit-at-a-time fix.

Maybe you got a buggy gcc version. The 2.6.5 based SLES9/i386
kernel is shipping with -funit-at-a-time compiled with a 3.3-hammer
compiler and I am not aware of any reports of stack overflow
(and that kernel is extremly well tested) 

IMHO it should be enabled on i386 in mainline, and if some gcc version
is determined to break it then it should be only explicitely 
disabled for that version. With the commonly used 3.3-hammer
compiler it seems to work fine.

> 
> x86-64 is a different architecture. It's possible its larger
> number of registers reduces spills enough that gcc's failure
> to merge stack slots doesn't matter.

The only reports of stack overflows on x86-64 were clear programmer
bugs (too large arrays/structures on the stack).

-Andi

Re: unit-at-a-time...

[Mikael Pettersson]

On 01 Nov 2004 02:39:41 +0100, Andi Kleen wrote:
>> Disabling unit-at-a-time for i386 is definitely correct.
>> I've personally observed horrible runtime corruption bugs
>> in early 2.6 kernels when they were compiled with gcc-3.4
>> without the -fno-unit-at-a-time fix.
>
>Maybe you got a buggy gcc version. The 2.6.5 based SLES9/i386
>kernel is shipping with -funit-at-a-time compiled with a 3.3-hammer
>compiler and I am not aware of any reports of stack overflow
>(and that kernel is extremly well tested) 

It happened when I added perfctr to a 2.6.5-based SuSE kernel,
and compiled the whole thing with gcc-3.4.0 (or 3.4.1, don't
remember). Perfctr normally adds a little stack usage to the
context-switch path, but gcc-3.4 made it much worse.
Disabling unit-at-a-time solved the problem.

/Mikael

Re: unit-at-a-time...

[Andi Kleen]

> It happened when I added perfctr to a 2.6.5-based SuSE kernel,
> and compiled the whole thing with gcc-3.4.0 (or 3.4.1, don't
> remember). Perfctr normally adds a little stack usage to the
> context-switch path, but gcc-3.4 made it much worse.
> Disabling unit-at-a-time solved the problem.

Better fix would have been a few strategic "noinline"s.
If you want noinline just say it explicitely.

Also I hope they were not all in the same callchain,
if yes you would have only hidden the problem.

-Andi