On Wed, 06 Feb 2008 17:34:39 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Wed, 06 Feb 2008 17:11:38 -0600
> > Eric Sandeen <[EMAIL PROTECTED]> wrote:
> >
> >> /*
> >> * recursively change the type of the mountpoint.
> >> + * noinline this do_mount helper to save do_mount stack space.
> >> */
> >> -static int do_change_type(struct nameidata *nd, int flag)
> >> +static noinline int do_change_type(struct nameidata *nd, int flag)
> >
> > What we could do here is defined a new noinline_because_of_stack_suckiness
> > and use that. Reasons:
> >
> > - self-documenting, so we don't need to comment each site
> >
> > - can be made a no-op for suitable __GNUC__ values if gcc ever fixes this
> >
> > - our children we can go through and delete them all when nobody is using
> > the offending gcc versions any more.
> >
> > what thinkest thou?
>
> Yes, sounds very good to me. I'm sure there are more places which could
> use this.
>
> Or perhaps there are some magic flags to gcc so that it doesn't inline
> so aggressively in situations like this? IOW is it gcc breakage, or
> design - but maybe with defaults that don't fit well in the limited
> stack... (well, I suppose the "for N mutually exclusive helper functions
> each with stack usage S, use about N*S stack when inlining them all" bit
> probably isn't a feature.)
The auto inlining is OK. The problem is that when gcc handles this:
static inline foo()
{
char a[10];
}
static inline bar()
{
char a[10];
}
zot()
{
foo();
bar();
}
it will use 20 bytes of stack instead of using the same 10 bytes for both
"calls". It doesn't need to do that, and other compilers avoid it, iirc.
Now, it _used_ to be the case that when presented with this:
foo()
{
{
char a[10];
bar(a);
}
{
char a[10];
bar(a);
}
}
gcc would also consume 20 bytes of stack. But I see that this is fixed in
gcc-4.0.3.
These two things are equivalent and hopefully gcc will soon fix the
inlined-functions-use-too-much-stack thing. Once that happens, we don't
need your patch.
> FWIW the XFS team finally just wrested control from GCC.
> http://oss.sgi.com/archives/xfs/2006-11/msg00195.html
>
yup.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
