__cpufreq_remove_dev() is called on multiple occasions: cpufreq_driver
unregister and cpu removals.
Current implementation of this routine is overly complex without much need. If
the cpu to be removed is the policy->cpu, we remove the policy first and add all
other cpus again from policy->cpus and
cpufreq core doesn't manage offline cpus and if driver->init() has returned
mask including offline cpus, it may result in unwanted behavior by cpufreq core
or governors.
We need to get only online cpus in this mask. There are two places to fix this
mask, cpufreq core and cpufreq driver. It makes s
Because cpufreq core and governors worry only about the online cpus, if a cpu is
hot [un]plugged, we must notify governors about it, otherwise be ready to expect
something unexpected.
We already have notifiers in the form of CPUFREQ_GOV_START/CPUFREQ_GOV_STOP, we
just need to call them now.
Signe
Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and
then checks if this cpu is already managed or not. And if it is already managed,
free its policy.
We can save all this if we somehow know cpu is managed or not in advance.
policy->related_cpus contains list of all valid
Hi Rafael,
As requested, i am resending all my cpufreq fixes together. I have added correct
Tested-by flags.
Viresh Kumar (5):
cpufreq: Manage only online cpus
cpufreq: Notify governors when cpus are hot-[un]plugged
cpufreq: Don't use cpu removed during cpufreq_driver_unregister
cpufreq:
This is how the core works:
cpufreq_driver_unregister()
- subsys_interface_unregister()
- for_each_cpu() call cpufreq_remove_dev(), i.e. 0,1,2,3,4 when we
unregister.
cpufreq_remove_dev():
- Remove policy node
- Call cpufreq_add_dev() for next cpu, sharing mask with removed cpu.
i.e.
On Sunday, December 16, 2012 11:20:08 AM Viresh Kumar wrote:
> cpufreq core doesn't manage offline cpus and if driver->init() has returned
> mask including offline cpus, it may result in unwanted behavior by cpufreq
> core
> or governors.
>
> We need to get only online cpus in this mask. There ar
*Ping!*
Happy New Year everyone. Is there any update on this? I think Francesco already
pointed out how to solve the last remaining issue with this, so I hope we can
now resubmit these patches and finally get them merged. Daniel?
___
linaro-dev mailing
On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
> Hi Tejun,
>
> On 4 January 2013 20:39, Tejun Heo wrote:
> > I don't know either. Changing behavior subtly like this is hard. I
> > usually try to spot some problem cases and try to identify patterns
> > there. Once you identify a few of
On Mon, 2013-01-07 at 10:59 +0530, Preeti U Murthy wrote:
> Hi Mike,
> Thank you very much for your inputs.Just a few thoughts so that we are
> clear with the problems so far in the scheduler scalability and in what
> direction we ought to move to correct them.
>
> 1. During fork or exec,the sche
On Thu, 2013-01-03 at 16:08 +0530, Preeti U Murthy wrote:
> Hi Mike,
>
> Thank you very much for your feedback.Considering your suggestions,I have
> posted out a
> proposed solution to prevent select_idle_sibling() from becoming a
> disadvantage to normal
> load balancing,rather aiding it.
>
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
> > By default, I would suggest for cache locality,
> > that we try to keep it on the same CPU. But if there's a better CPU to
> > run on, it runs there.
>
> That would break our intention behind this routine. We should run
> it on a cpu whic
On Sat, 2013-01-05 at 09:13 +0100, Mike Galbraith wrote:
> I still have a 2.6-rt problem I need to find time to squabble with, but
> maybe I'll soonish see if what you did plus what I did combined works
> out on that 4x10 core box where current is _so_ unbelievably horrible.
> Heck, it can't get a
On 01/08/2013 04:08 AM, Peter Maydell wrote:
> The translator sources (as and when we implement a
> TCG QEMU target for this) should live under the existing target-arm.
Of this I'm not certain, given that A64 is different enough from A32
to warrant a brand new gcc backend. I havn't tried to rever
On Thu, 2013-01-03 at 16:08 +0530, Preeti U Murthy wrote:
> Hi Mike,
>
> Thank you very much for your feedback.Considering your suggestions,I have
> posted out a
> proposed solution to prevent select_idle_sibling() from becoming a
> disadvantage to normal
> load balancing,rather aiding it.
>
On Thu, 2013-01-03 at 16:08 +0530, Preeti U Murthy wrote:
> Subject: [PATCH] sched: Merge select_idle_sibling with the behaviour of
> SD_BALANCE_WAKE
>
> The function of select_idle_sibling() is to place the woken up task in the
> vicinity of the waking cpu or on the previous cpu depending on wh
hey i am also trying to boot linaro on Hackberry board. as i want linaro source
code for my project, how can i get it?
git clone git://git.linaro.org/kernel/linux-linaro-3.1.git is this link
downloads linaro source code?
___
linaro-dev mailing list
17 matches
Mail list logo
