public inbox for cpufreq@vger.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: cpufreq@vger.kernel.org
Subject: [Bug 55091] cpufreq governors woks crazy
Date: Tue, 12 Mar 2013 11:15:49 +0000 (UTC)	[thread overview]
Message-ID: <20130312111549.B0EB811F877@bugzilla.kernel.org> (raw)
In-Reply-To: <bug-55091-12968@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=55091


Viresh Kumar <viresh.kumar@linaro.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viresh.kumar@linaro.org




--- Comment #1 from Viresh Kumar <viresh.kumar@linaro.org>  2013-03-12 11:15:49 ---
Hi,

I was the guy behind most of the cpufreq core updates in this kernel release. I
haven't tried to reproduce the problem you got (was very busy with some other
activity), but i am trying to analyse what may cause it. Following are the
important updates that i can make out from: 'git diff v3.8..v3.9-rc2'

- Locking Fixes
- policy->cpus and policy->related_cpus fixups
- simplification of cpu hotplug path in cpufreq core
- removing redundant code between governors

I don't really think any of the above can cause this problem, unless there is a
bug somewhere.

- per cpu timer for both ondemand and conservative:

commit 2abfa876f1117b0ab45f191fb1f82c41b1cbc8fe
Author: Rickard Andersson <rickard.andersson@stericsson.com>
Date:   Thu Dec 27 14:55:38 2012 +0000

    cpufreq: handle SW coordinated CPUs

    This patch fixes a bug that occurred when we had load on a secondary CPU
    and the primary CPU was sleeping. Only one sampling timer was spawned
    and it was spawned as a deferred timer on the primary CPU, so when a
    secondary CPU had a change in load this was not detected by the cpufreq
    governor (both ondemand and conservative).

    This patch make sure that deferred timers are run on all CPUs in the
    case of software controlled CPUs that run on the same frequency.



This can be behind all the problem you are facing. Can you try reverting all
patches including and after this patch?

If any of the cpu is loaded enough, then you will see some freq used (based on
the load). Whereas, earlier if cpu0 goes down, then we were just not
re-evaluating load at all.

--
viresh

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

  reply	other threads:[~2013-03-12 11:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11 21:58 [Bug 55091] New: cpufreq governors woks crazy bugzilla-daemon
2013-03-12 11:15 ` bugzilla-daemon [this message]
2013-03-26  7:44 ` [Bug 55091] " bugzilla-daemon
2013-03-26  7:45 ` bugzilla-daemon
2013-03-26 16:39 ` bugzilla-daemon
2013-04-01  5:50 ` bugzilla-daemon

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=20130312111549.B0EB811F877@bugzilla.kernel.org \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=cpufreq@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox