All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
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: Sun, 05 Apr 2015 19:15:02 -0700	[thread overview]
Message-ID: <1428286502.2775.92.camel@perches.com> (raw)
In-Reply-To: <20150406010025.GA5956@opentech.at>

On Mon, 2015-04-06 at 03:00 +0200, Nicholas Mc Guire wrote:
> 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.

Hi Nicholas.

Your inline version has not worked with any of
x86-64 gcc 4.4, 4.6, 4.7, or 4.9

I suggest you add some lines to
lib/test_module.c/test_module_init like:

	unsigned int m;

	for (m = 10; m < 200; m += 10)
		pr_info("msecs_to_jiffies(%u) is %lu\n",
			m, msecs_to_jiffies(m));

	pr_info("msecs_to_jiffies(%u) is %lu\n",
		10, msecs_to_jiffies(10));
	pr_info("msecs_to_jiffies(%u) is %lu\n",
		100, msecs_to_jiffies(100));
	pr_info("msecs_to_jiffies(%u) is %lu\n",
		1000, msecs_to_jiffies(1000));

Then it's pretty easy to look at the assembly/.lst file

Your inline function doesn't allow gcc to precompute
the msecs_to_jiffies value.  The macro one does for all
those gcc versions.

Try it and look at the generated .lst files with and
without the patch I sent.

cheers, Joe


  reply	other threads:[~2015-04-06  2:15 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
2015-04-06  2:15       ` Joe Perches [this message]
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=1428286502.2775.92.camel@perches.com \
    --to=joe@perches.com \
    --cc=ahh@google.com \
    --cc=der.herr@hofr.at \
    --cc=hofrat@osadl.org \
    --cc=hpa@zytor.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.