From: Shreyas B Prabhu <shreyas@linux.vnet.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org
Cc: 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:31:35 +0530 [thread overview]
Message-ID: <576D595F.9090001@linux.vnet.ibm.com> (raw)
In-Reply-To: <14940457.SEYBmqcunj@wuerfel>
On 06/24/2016 03:41 PM, Arnd Bergmann wrote:
> On Friday, June 24, 2016 9:00:48 AM CEST David Laight wrote:
>> The intent of the >> 10 was probably to avoid an expensive 64bit divide.
>> So maybe something like:
>> diff = time_end - time_start;
>> if (diff >= INT_MAX/2)
>> diff_32 = INT_MAX/2/1000;
>> else
>> diff_32 = diff;
>> diff_32 += diff_32 >> 6;
>> diff_32 >>= 10;
>> }
>>
>> Adding an extra 1/32 makes the division by be something slightly below 1000.
>
> Why not change the definition of the time to nanoseconds and update
> the users accordingly?
>
> I see that cpuidle_enter_state() writes to the last_residency value,
> and it is read in three places: ladder_select_state(), menu_update()
> and show_state_time() (for sysfs).
>
Updating show_state_time() to convert ns to us gets bit messy since
show_state_##_name which is used for disable, usage and time simply
returns state_usage->_name. And state_usage->time updation happens in
cpuidle_enter_state() itself.
> 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?
--Shreyas
next prev parent reply other threads:[~2016-06-24 16:01 UTC|newest]
Thread overview: 16+ 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 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 [this message]
2016-06-24 19:43 ` Arnd Bergmann
2016-06-27 8:59 ` David Laight
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 9:30 ` kbuild test robot
2016-06-24 10:27 ` kbuild test robot
2016-06-24 10:27 ` kbuild test robot
2016-06-24 12:10 ` 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=576D595F.9090001@linux.vnet.ibm.com \
--to=shreyas@linux.vnet.ibm.com \
--cc=David.Laight@aculab.com \
--cc=anton@samba.org \
--cc=arnd@arndb.de \
--cc=daniel.lezcano@linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rjw@rjwysocki.net \
/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.