From: Michael Ellerman <mpe@ellerman•id.au>
To: Anton Blanchard <anton@samba•org>
Cc: linuxppc-dev@lists•ozlabs.org, Alan Modra <amodra@gmail•com>,
benh@kernel•crashing.org, paulus@samba•org,
Ulrich Weigand <Ulrich.Weigand@de•ibm.com>,
Michael Gschwind <mkg@us•ibm.com>,
Bill Schmidt <wschmidt@us•ibm.com>
Subject: Re: RFC: Reducing the number of non volatile GPRs in the ppc64 kernel
Date: Fri, 14 Aug 2015 12:01:10 +1000 [thread overview]
Message-ID: <1439517670.2056.2.camel@ellerman.id.au> (raw)
In-Reply-To: <20150805140300.218ef661@kryten>
On Wed, 2015-08-05 at 14:03 +1000, Anton Blanchard wrote:
> Hi,
>
> While looking at traces of kernel workloads, I noticed places where gcc
> used a large number of non volatiles. Some of these functions
> did very little work, and we spent most of our time saving the
> non volatiles to the stack and reading them back.
>
> It made me wonder if we have the right ratio of volatile to non
> volatile GPRs. Since the kernel is completely self contained, we could
> potentially change that ratio.
>
> Attached is a quick hack to gcc and the kernel to decrease the number
> of non volatile GPRs to 8. I'm not sure if this is a good idea (and if
> the volatile to non volatile ratio is right), but this gives us
> something to play with.
OK, interesting idea. Can't say I'd ever though of that.
I'm thinking we'd want some pretty solid analysis of the resulting code-gen and
real world perf before we made a switch like that.
Presumably it's going to hurt our null syscall, due to the added save/restores,
but hopefully help with paths that do actual work.
If the caller is actually using the non-volatiles then presumably it will be a
wash, because the caller will have to do the save anyway. Though maybe it would
still be a win because the caller can do the saves & restores when it needs to
rather than all in a block.
I'm also not clear on how it would affect folks who build modules separate from
the kernel. We'd have to make sure they had the right GCC, or things would go
badly wrong, unless it can be done with command line flags? I don't know how
much we care about that but distros presumably do.
cheers
prev parent reply other threads:[~2015-08-14 2:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 4:03 RFC: Reducing the number of non volatile GPRs in the ppc64 kernel Anton Blanchard
2015-08-05 4:19 ` Segher Boessenkool
2015-08-07 5:55 ` Bill Schmidt
2015-08-10 4:52 ` Anton Blanchard
2015-08-11 20:08 ` Segher Boessenkool
2015-08-11 22:18 ` Segher Boessenkool
2015-08-13 21:04 ` Anton Blanchard
2015-08-14 2:01 ` Michael Ellerman [this message]
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=1439517670.2056.2.camel@ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=Ulrich.Weigand@de$(echo .)ibm.com \
--cc=amodra@gmail$(echo .)com \
--cc=anton@samba$(echo .)org \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mkg@us$(echo .)ibm.com \
--cc=paulus@samba$(echo .)org \
--cc=wschmidt@us$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox