All of lore.kernel.org
 help / color / mirror / Atom feed
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 06:26:54 +0200	[thread overview]
Message-ID: <20150406042654.GA28155@opentech.at> (raw)
In-Reply-To: <1428286502.2775.92.camel@perches.com>

On Sun, 05 Apr 2015, Joe Perches wrote:

> 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.
>
will do that - thanks !

Managed to fool my self - the difference in the .lst/.s files is
simply due to chaning msecs_to_jiffies being inline
(which it was not) and thus it "vanished" - kind of stupid - sorry
back to gcc manual first - need to understand __builtin_constant_p
better and the constraints - from all that I understood it should
be doable both as macro and inline.

thx!
hofrat

  reply	other threads:[~2015-04-06  4:26 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
2015-04-06  4:26         ` Nicholas Mc Guire [this message]
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=20150406042654.GA28155@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.