From: Nicholas Mc Guire <der.herr@hofr.at>
To: Joe Perches <joe@perches.com>
Cc: Nicholas Mc Guire <hofrat@osadl.org>,
Michal Marek <mmarek@suse.cz>,
Masahiro Yamada <yamada.m@jp.panasonic.com>,
Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Alvin" <hpa@zytor.com>,
John Stultz <john.stultz@linaro.org>,
Andrew Hunter <ahh@google.com>, Paul Turner <pjt@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] time: allow gcc to fold constants when using msecs_to_jiffies
Date: Mon, 6 Apr 2015 03:00:25 +0200 [thread overview]
Message-ID: <20150406010025.GA5956@opentech.at> (raw)
In-Reply-To: <1428278627.2775.75.camel@perches.com>
On Sun, 05 Apr 2015, Joe Perches wrote:
> On Sun, 2015-04-05 at 09:23 +0200, Nicholas Mc Guire wrote:
> > The majority of the msecs_to_jiffies() users in the kernel are passing in
> > constants which would allow gcc to do constant folding by checking with
> > __builtin_constant_p() in msecs_to_jiffies().
> >
> > The original msecs_to_jiffies is renamed to __msecs_to_jiffies and aside
> > from the removal of the check for negative values being moved out, is
> > unaltered.
>
> At least for gcc 4.9, this doesn't allow the compiler
> to optimize / precalculation msecs_to_jiffies calls
> with a constant.
>
> This does: (on top of your patch x86-64 defconfig)
>
> $ size vmlinux.o.*
> text data bss dec hex filename
> 11770523 1505971 1018454 14294948 da1fa4 vmlinux.o.next-b0a12fb5bc8
> 11770530 1505971 1018454 14294955 da1fab vmlinux.o.next-b0a12fb5bc8-inline
> 11768734 1505971 1018454 14293159 da18a7 vmlinux.o.next-b0a12fb5bc8-macro
>
> I think this should still move the if (m) < 0 back into the
> original __msecs_to_jiffies function.
>
could you check if you can reproduce the results below ?
my assumption was that gcc would always optimize out an
if(CONST < 0) return CONST; reducing it to the return CONST;
only and thus this should not make any difference but Im not
that familiar with gcc.
gcc versions here are:
for x86 gcc version 4.7.2 (Debian 4.7.2-5)
for powerpc it is a gcc version 4.9.2 (crosstool-NG 1.20.0)
for arm gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
Procedure used:
root@debian:~/linux-next# make distclean
root@debian:~/linux-next# make defconfig
root@debian:~/linux-next# make drivers/net/wireless/p54/p54usb.lst
root@debian:~/linux-next# make drivers/net/wireless/p54/p54usb.s
same setup in unpatched /usr/src/linux-next/
e.g:
root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.c
timeout = jiffies + msecs_to_jiffies(1000);
timeout = jiffies + msecs_to_jiffies(1000);
So both calls are constants and should be optimized out if it works as
expected.
without the patch applied:
root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.s
call msecs_to_jiffies #
call msecs_to_jiffies #
root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.lst
timeout = jiffies + msecs_to_jiffies(1000);
e19: R_X86_64_PC32 msecs_to_jiffies+0xfffffffffffffffc
timeout = jiffies + msecs_to_jiffies(1000);
timeout = jiffies + msecs_to_jiffies(1000);
fd8: R_X86_64_PC32 msecs_to_jiffies+0xfffffffffffffffc
timeout = jiffies + msecs_to_jiffies(1000);
with the patch applied this then gives me:
root@debian:~/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.s
root@debian:~/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.lst
timeout = jiffies + msecs_to_jiffies(1000);
timeout = jiffies + msecs_to_jiffies(1000);
timeout = jiffies + msecs_to_jiffies(1000);
timeout = jiffies + msecs_to_jiffies(1000);
Conversely in kernel/sched/core.c the msecs_to_jiffies is not a constant
and the result is that it calls __msecs_to_jiffies
patched:
root@debian:~/linux-next# grep msecs_to_jiffies kernel/sched/core.s
call __msecs_to_jiffies #
unpatched:
root@debian:/usr/src/linux-next# grep msecs_to_jiffies kernel/sched/core.s
call msecs_to_jiffies #
Could you check if you get these results for this test-case ?
If this really were compiler dependant that would be very bad.
I did move the < 0 check - but that did not change the situation here.
but it well may be that there are some cases where this does make a
difference
thx!
hofrat
next prev parent reply other threads:[~2015-04-06 1:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 7:23 [PATCH 0/3] time: use __builtin_constant_p() in msecs_to_jiffies Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 1/3] time: move timeconst.h into include/generated Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 2/3] time: allow gcc to fold constants when using msecs_to_jiffies Nicholas Mc Guire
2015-04-06 0:03 ` Joe Perches
2015-04-06 1:00 ` Nicholas Mc Guire [this message]
2015-04-06 2:15 ` Joe Perches
2015-04-06 4:26 ` Nicholas Mc Guire
2015-04-06 4:33 ` Joe Perches
2015-04-06 6:40 ` Nicholas Mc Guire
2015-04-06 7:12 ` Joe Perches
2015-04-06 7:21 ` Nicholas Mc Guire
2015-04-12 8:36 ` Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 3/3] time: update msecs_to_jiffies doc and move to kernel-doc format Nicholas Mc Guire
2015-04-05 9:33 ` [PATCH 0/3] time: use __builtin_constant_p() in msecs_to_jiffies Joe Perches
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=20150406010025.GA5956@opentech.at \
--to=der.herr@hofr.at \
--cc=ahh@google.com \
--cc=hofrat@osadl.org \
--cc=hpa@zytor.com \
--cc=joe@perches.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=pjt@google.com \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=yamada.m@jp.panasonic.com \
/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.