linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Shreyas B Prabhu <shreyas@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org,
	David Laight <David.Laight@aculab.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"anton@samba.org" <anton@samba.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v2] cpuidle: Fix last_residency division
Date: Fri, 24 Jun 2016 21:43:13 +0200	[thread overview]
Message-ID: <3748080.8f21OXxXix@wuerfel> (raw)
In-Reply-To: <576D595F.9090001@linux.vnet.ibm.com>

On Friday, June 24, 2016 9:31:35 PM CEST Shreyas B Prabhu wrote:
> > If those functions are called less often than cpuidle_enter_state(),
> > we could just move the division there. Since the divisor is constant,
> > do_div() can convert it into a multiply and shift, or we could use
> > your the code you suggest above, or use a 32-bit division most of
> > the time:
> > 
> >       if (diff <= UINT_MAX)
> >               diff_32 = (u32)diff / NSECS_PER_USEC;
> >       else
> >               diff_32 = div_u64(diff, NSECS_PER_USEC;
> > 
> > which gcc itself will turn into a multiplication or series of
> > shifts on CPUs on which that is faster.
> >
> I'm not sure which division method of the three suggested here to use.
> Does anyone have a strong preference?
> 

It depends on how accurate we want it and how long we expect
the times to be. The optimization for the 4.2 second cutoff
for doing a 32-bit division only makes sense if the majority
of the sleep times are below that.

	Arnd

  reply	other threads:[~2016-06-24 19:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24  8:23 [PATCH v2] cpuidle: Fix last_residency division Shreyas B. Prabhu
2016-06-24  9:00 ` David Laight
2016-06-24 10:05   ` Daniel Lezcano
2016-06-24 10:11   ` Arnd Bergmann
2016-06-24 16:01     ` Shreyas B Prabhu
2016-06-24 19:43       ` Arnd Bergmann [this message]
2016-06-27  8:59         ` David Laight
2016-06-29  7:00           ` Shreyas B Prabhu
2016-06-24  9:30 ` kbuild test robot
2016-06-24 10:27 ` kbuild test robot
2016-06-24 12:10 ` kbuild test robot

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=3748080.8f21OXxXix@wuerfel \
    --to=arnd@arndb.de \
    --cc=David.Laight@aculab.com \
    --cc=anton@samba.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rjw@rjwysocki.net \
    --cc=shreyas@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).