LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] reduce large do_mount stack usage with noinlines
Date: Wed, 6 Feb 2008 15:46:17 -0800	[thread overview]
Message-ID: <20080206154617.9bb11169.akpm@linux-foundation.org> (raw)
In-Reply-To: <47AA440F.8030403@redhat.com>

On Wed, 06 Feb 2008 17:34:39 -0600
Eric Sandeen <sandeen@redhat.com> wrote:

> Andrew Morton wrote:
> > On Wed, 06 Feb 2008 17:11:38 -0600
> > Eric Sandeen <sandeen@redhat.com> 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.

  reply	other threads:[~2008-02-06 23:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-06 22:13 Eric Sandeen
2008-02-06 22:34 ` Andrew Morton
2008-02-06 22:54   ` Arjan van de Ven
2008-02-06 23:01     ` Eric Sandeen
2008-02-06 22:55   ` Eric Sandeen
2008-02-06 23:11   ` Eric Sandeen
2008-02-06 23:22     ` Andrew Morton
2008-02-06 23:34       ` Eric Sandeen
2008-02-06 23:46         ` Andrew Morton [this message]
2008-02-07 23:08       ` Eric Sandeen
2008-02-07 23:23         ` Arjan van de Ven
2008-02-07 23:26         ` Andrew Morton
2008-02-08 16:50       ` Andi Kleen
2008-02-08 16:54         ` Eric Sandeen
2008-02-08 17:23           ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080206154617.9bb11169.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --subject='Re: [PATCH] reduce large do_mount stack usage with noinlines' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).