From: Denys Vlasenko <vda.linux@googlemail.com>
To: David Miller <davem@davemloft.net>
Cc: mpatocka@redhat.com, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: [3/10 PATCH] inline wake_up_bit
Date: Thu, 26 Jun 2008 03:35:59 +0000 [thread overview]
Message-ID: <200806260535.59306.vda.linux@googlemail.com> (raw)
In-Reply-To: <20080625.172838.242554644.davem@davemloft.net>
On Thursday 26 June 2008 02:28, David Miller wrote:
> From: Denys Vlasenko <vda.linux@googlemail.com>
> Date: Wed, 25 Jun 2008 22:37:58 +0200
> > > Sparc64 has register windows: it passes arguments in registers, but it
> > > must allocate space for that registers. If the call stack is too deep (8
> > > levels), the CPU runs out of registers and starts spilling the registers
> > > of the function 8-levels-deep to the stack.
> > >
> > > The stack usage could be reduced to 176 bytes with little work from gcc
> > > developers and to 128 bytes with more work (ABI change). If you wanted to
> >
> > Wow, it's nearly x2 reduction.
> >
> > ABI change in not a problem for kernel, since it is a "freestanding
> > application". Exactly like i386 switched to regparm, which is a different ABI.
>
> Except that nobody has written this code and therefore being about to
> use this unimplemented compiler facility to get correctness is not
> tenable.
Inlining everything is even less tenable. Why architectures which do not
require 128+ bytes of stack for every function call should suffer?
I am all for fixing code where there are extra useless levels of calls,
but in this example I pointed out that patch adds inlines too liberally.
Do you agree that blowing up every wake_up_bit() into half a dozen
or more C lines is not what we want?
--
vda
WARNING: multiple messages have this Message-ID (diff)
From: Denys Vlasenko <vda.linux@googlemail.com>
To: David Miller <davem@davemloft.net>
Cc: mpatocka@redhat.com, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: [3/10 PATCH] inline wake_up_bit
Date: Thu, 26 Jun 2008 05:35:59 +0200 [thread overview]
Message-ID: <200806260535.59306.vda.linux@googlemail.com> (raw)
In-Reply-To: <20080625.172838.242554644.davem@davemloft.net>
On Thursday 26 June 2008 02:28, David Miller wrote:
> From: Denys Vlasenko <vda.linux@googlemail.com>
> Date: Wed, 25 Jun 2008 22:37:58 +0200
> > > Sparc64 has register windows: it passes arguments in registers, but it
> > > must allocate space for that registers. If the call stack is too deep (8
> > > levels), the CPU runs out of registers and starts spilling the registers
> > > of the function 8-levels-deep to the stack.
> > >
> > > The stack usage could be reduced to 176 bytes with little work from gcc
> > > developers and to 128 bytes with more work (ABI change). If you wanted to
> >
> > Wow, it's nearly x2 reduction.
> >
> > ABI change in not a problem for kernel, since it is a "freestanding
> > application". Exactly like i386 switched to regparm, which is a different ABI.
>
> Except that nobody has written this code and therefore being about to
> use this unimplemented compiler facility to get correctness is not
> tenable.
Inlining everything is even less tenable. Why architectures which do not
require 128+ bytes of stack for every function call should suffer?
I am all for fixing code where there are extra useless levels of calls,
but in this example I pointed out that patch adds inlines too liberally.
Do you agree that blowing up every wake_up_bit() into half a dozen
or more C lines is not what we want?
--
vda
next prev parent reply other threads:[~2008-06-26 3:35 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 5:54 [10 PATCHES] inline functions to avoid stack overflow Mikulas Patocka
2008-06-24 5:54 ` Mikulas Patocka
2008-06-24 5:55 ` [1/10 PATCH] inline __queue_work Mikulas Patocka
2008-06-24 5:55 ` Mikulas Patocka
2008-06-24 5:56 ` [2/10 PATCH] inline inline-generic_writepages.patch Mikulas Patocka
2008-06-24 5:56 ` Mikulas Patocka
2008-06-24 5:57 ` [3/10 PATCH] inline wake_up_bit Mikulas Patocka
2008-06-24 5:57 ` Mikulas Patocka
2008-06-25 14:17 ` Denys Vlasenko
2008-06-25 14:17 ` Denys Vlasenko
2008-06-25 14:36 ` Mikulas Patocka
2008-06-25 14:36 ` Mikulas Patocka
2008-06-25 15:24 ` Denys Vlasenko
2008-06-25 15:24 ` Denys Vlasenko
2008-06-25 16:01 ` Mikulas Patocka
2008-06-25 16:01 ` Mikulas Patocka
2008-06-25 20:37 ` Denys Vlasenko
2008-06-25 20:37 ` Denys Vlasenko
2008-06-26 0:28 ` David Miller
2008-06-26 0:28 ` David Miller
2008-06-26 3:35 ` Denys Vlasenko [this message]
2008-06-26 3:35 ` Denys Vlasenko
2008-06-26 4:18 ` David Miller
2008-06-26 4:18 ` David Miller
2008-06-26 18:22 ` Pavel Machek
2008-06-26 18:22 ` Pavel Machek
2008-06-25 22:23 ` David Miller
2008-06-25 22:23 ` David Miller
2008-06-25 22:30 ` David Miller
2008-06-25 22:30 ` David Miller
2008-06-24 5:57 ` [4/10 PATCH] inline __wake_up_bit Mikulas Patocka
2008-06-24 5:57 ` Mikulas Patocka
2008-06-24 5:58 ` [5/10 PATCH] inline __wake_up Mikulas Patocka
2008-06-24 5:58 ` Mikulas Patocka
2008-06-24 5:59 ` [6/10 PATCH] inline default_wake_function Mikulas Patocka
2008-06-24 5:59 ` Mikulas Patocka
2008-06-24 5:59 ` [6/10 PATCH] inline autoremove_wake_function Mikulas Patocka
2008-06-24 5:59 ` Mikulas Patocka
2008-06-24 6:01 ` [8/10 PATCH] inline filemap_fdatawrite Mikulas Patocka
2008-06-24 6:01 ` Mikulas Patocka
2008-06-24 6:01 ` [9/10 PATCH] inline dm-kcopyd-inline-wake.patch Mikulas Patocka
2008-06-24 6:01 ` Mikulas Patocka
2008-06-24 6:03 ` [10/10 PATCH] inline dispatch_job Mikulas Patocka
2008-06-24 6:03 ` Mikulas Patocka
2008-06-24 6:06 ` [PATCH] limit irq nesting Mikulas Patocka
2008-06-24 6:06 ` Mikulas Patocka
2008-06-24 7:01 ` [10 PATCHES] inline functions to avoid stack overflow Ingo Molnar
2008-06-24 7:01 ` Ingo Molnar
[not found] ` <486216E7.8000002@aitel.hist.no>
2008-06-25 12:53 ` Mikulas Patocka
2008-06-25 12:53 ` Mikulas Patocka
2008-06-25 22:09 ` David Miller
2008-06-25 22:09 ` David Miller
2008-06-26 6:32 ` Bart Van Assche
2008-06-26 6:32 ` Bart Van Assche
2008-06-26 9:06 ` David Miller
2008-06-26 9:06 ` David Miller
2008-07-02 4:39 ` Mikulas Patocka
2008-07-02 4:39 ` Mikulas Patocka
2008-07-02 4:45 ` David Miller
2008-07-02 4:45 ` David Miller
2008-07-03 21:12 ` Mikulas Patocka
2008-07-03 21:12 ` Mikulas Patocka
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=200806260535.59306.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=sparclinux@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.