All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Doug Smythies" <dsmythies@telus.net>
To: 'Prarit Bhargava' <prarit@redhat.com>
Cc: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
	linux-kernel@vger.kernel.org,
	'Kristen Carlson Accardi' <kristen@linux.intel.com>,
	'Viresh Kumar' <viresh.kumar@linaro.org>,
	linux-pm@vger.kernel.org
Subject: RE: [PATCH] cpufreq, Fix overflow in busy_scaled due to long delay
Date: Thu, 11 Jun 2015 09:17:38 -0700	[thread overview]
Message-ID: <000901d0a462$239b6080$6ad22180$@net> (raw)
In-Reply-To: <5579A29B.8050304@redhat.com>


On 2015.06.11 08:01 Prarit Bhargava wrote:
> On 06/11/2015 10:51 AM, Doug Smythies wrote:
>> 
>> On 2015.06.10 16:46 Rafael J. Wysocki wrote:
>>> On Wednesday, June 10, 2015 09:18:45 AM Prarit Bhargava wrote:
>>>> I looked into switching to div64_s64() instead of the 32-bit version in
>>>> div_fp(), however, this would result in sample_ratio and core_busy returning
>>>> 0 which is something we don't want.
>> 
>> ???
>> Due to a great many overflow related issues, div_fp() was changed to div64_s64()
>> a long time ago.

> Doug,
>
> Nope -- in a linux.git tree (up-to-date as of 7:00AM ET this AM)
>
> static inline int32_t div_fp(int32_t x, int32_t y)
> {
>        return div_s64((int64_t)x << FRAC_BITS, y);
> }

> If we do want this to be div64_s64, I can make that change, however, I feel that
> a long delay like this should be ignored in the performance calculations in the
> driver and that's why I chose to go the direction I did.

Prarit,

Apologies to you and the list for the distraction. I mis-read "div_s64" as "div64_s64".
Your suggestion is a good one.

I do maintain that my point about the duration method being flawed is valid.
I proposed a fix for that some time ago.



WARNING: multiple messages have this Message-ID (diff)
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Prarit Bhargava'" <prarit@redhat.com>
Cc: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
	<linux-kernel@vger.kernel.org>,
	"'Kristen Carlson Accardi'" <kristen@linux.intel.com>,
	"'Viresh Kumar'" <viresh.kumar@linaro.org>,
	<linux-pm@vger.kernel.org>
Subject: RE: [PATCH] cpufreq, Fix overflow in busy_scaled due to long delay
Date: Thu, 11 Jun 2015 09:17:38 -0700	[thread overview]
Message-ID: <000901d0a462$239b6080$6ad22180$@net> (raw)
In-Reply-To: <5579A29B.8050304@redhat.com>


On 2015.06.11 08:01 Prarit Bhargava wrote:
> On 06/11/2015 10:51 AM, Doug Smythies wrote:
>> 
>> On 2015.06.10 16:46 Rafael J. Wysocki wrote:
>>> On Wednesday, June 10, 2015 09:18:45 AM Prarit Bhargava wrote:
>>>> I looked into switching to div64_s64() instead of the 32-bit version in
>>>> div_fp(), however, this would result in sample_ratio and core_busy returning
>>>> 0 which is something we don't want.
>> 
>> ???
>> Due to a great many overflow related issues, div_fp() was changed to div64_s64()
>> a long time ago.

> Doug,
>
> Nope -- in a linux.git tree (up-to-date as of 7:00AM ET this AM)
>
> static inline int32_t div_fp(int32_t x, int32_t y)
> {
>        return div_s64((int64_t)x << FRAC_BITS, y);
> }

> If we do want this to be div64_s64, I can make that change, however, I feel that
> a long delay like this should be ignored in the performance calculations in the
> driver and that's why I chose to go the direction I did.

Prarit,

Apologies to you and the list for the distraction. I mis-read "div_s64" as "div64_s64".
Your suggestion is a good one.

I do maintain that my point about the duration method being flawed is valid.
I proposed a fix for that some time ago.



  reply	other threads:[~2015-06-11 16:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 13:18 [PATCH] cpufreq, Fix overflow in busy_scaled due to long delay Prarit Bhargava
2015-06-10 23:45 ` Rafael J. Wysocki
2015-06-10 23:45   ` Rafael J. Wysocki
2015-06-11 14:51   ` Doug Smythies
2015-06-11 14:51     ` Doug Smythies
2015-06-11 14:58     ` Prarit Bhargava
2015-06-11 15:00     ` Prarit Bhargava
2015-06-11 16:17       ` Doug Smythies [this message]
2015-06-11 16:17         ` Doug Smythies
2015-06-11 16:59         ` Prarit Bhargava

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='000901d0a462$239b6080$6ad22180$@net' \
    --to=dsmythies@telus.net \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.org \
    /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.