LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] reduce large do_mount stack usage with noinlines
Date: Wed, 06 Feb 2008 16:55:51 -0600	[thread overview]
Message-ID: <47AA3AF7.7020609@redhat.com> (raw)
In-Reply-To: <20080206143457.03e8741d.akpm@linux-foundation.org>

Andrew Morton wrote:

> Does the patch actually help?  I mean, if a() calls b() and both use N
> bytes of locals, our worst-case stack usage remains ~2N whether or not b()
> was inlined in a()?  In fact, uninlining makes things a little worse due to
> callframe stuff.

I think it does.

[linux-2.6.24-mm1]$ make fs/namespace.o > /dev/null
[linux-2.6.24-mm1]$ objdump -d fs/namespace.o | scripts/checkstack.pl
x86_64 | grep do_mount
0x00002307 do_mount [namespace.o]:                      616
[linux-2.6.24-mm1]$ quilt push
Applying patch patches/do_mount_stack
patching file fs/namespace.c

Now at patch patches/do_mount_stack
[linux-2.6.24-mm1]$ make fs/namespace.o > /dev/null
[linux-2.6.24-mm1]$ objdump -d fs/namespace.o | scripts/checkstack.pl
x86_64 | grep do_mount
0x00002a8b do_mount [namespace.o]:                      168

So clearly that one function is reduced.  But it's more than that....

I guess the problem is a() calls b() or c() or d() or e() or f(), and
gcc adds up all that stack usage, or seems to, and we get more like 6N
regardless of the path taken.

For example, 2 of the helper functions, once un-inlined, are:

0x00001fd9 do_move_mount [namespace.o]:                 288
0x00001e94 do_loopback [namespace.o]:                   168

so it looks like we do carry that baggage even if we go the
do_new_mount() path for example.

>> -static int do_change_type(struct nameidata *nd, int flag)
>> +static noinline int do_change_type(struct nameidata *nd, int flag)
> 
> There's no way for the reader to work out why this is here, so I do think
> it should be commented somewhere.

Ok, good point, will resend... want a comment on each, or perhaps above
do_mount?  I suppose on each.

-Eric

  parent reply	other threads:[~2008-02-06 22:56 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 [this message]
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
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=47AA3AF7.7020609@redhat.com \
    --to=sandeen@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).