On 5 June 2013 08:54, Xiaoguang Chen <chenxg.marvell(a)gmail.com> wrote:
> Hi, Guys
Hi Xiaoguang,
> I met another question for cpufreq governor. When hotplug out one cpu,
> cpufreq will remove the cpu device and also call governor stop, if
> there are more than 1 cpu and cpu0 is the root for cpufreq, other cpus
> are linked to cpu0. then policy->cpu is 0 always.
Not really.. There are situations when this will not hold true..
If you hot-unplug cpu0, then next cpu in line, i.e. cpu 1, will become
policy->cpu :)
> in userspace governor, when governor stop is called, it will set
> per_cpu(cpu_is_managed, cpu) = 0
To make it clear, cpu_is_managed isn't telling which cpu is managing
'cpu' but if governor is enabled for cpu 'cpu' or not.
> but the cpu is policy->cpu which is 0 always.
>
> case CPUFREQ_GOV_STOP:
> mutex_lock(&userspace_mutex);
> cpus_using_userspace_governor--;
> if (cpus_using_userspace_governor == 0) {
> cpufreq_unregister_notifier(
> &userspace_cpufreq_notifier_block,
> CPUFREQ_TRANSITION_NOTIFIER);
> }
>
> per_cpu(cpu_is_managed, cpu) = 0;
> per_cpu(cpu_min_freq, cpu) = 0;
> per_cpu(cpu_max_freq, cpu) = 0;
> per_cpu(cpu_set_freq, cpu) = 0;
> pr_debug("managing cpu %u stopped\n", cpu);
> mutex_unlock(&userspace_mutex);
> break;
>
>
> also in userspace governor store_setspeed function cpufreq_set will
> retun error if per_cpu(cpu_is_managed, cpu) is 0 which means it will
> not change frequency .
>
> static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq)
> {
> int ret = -EINVAL;
>
> pr_debug("cpufreq_set for cpu %u, freq %u kHz\n", policy->cpu, freq);
>
> mutex_lock(&userspace_mutex);
> if (!per_cpu(cpu_is_managed, policy->cpu))
> goto err;
>
> per_cpu(cpu_set_freq, policy->cpu) = freq;
> ...........
>
>
>
> So consider below case:
> 1) cpu0 tries to hotplug cpu3, it calls userspace governor stop
> function, it should stop cpu3's userspace governor, but it actually
> set cpu0's per_cpu(cpu_is_managed, cpu) to 0.
> 2) cpu0 tries to change cpu freuqency through userspace governor, but
> it will never succeed since cpufreq_set will return err if cpu0'
> percpu variable cpu_is_managed is 0.
> 3) unless there is another cpu hotplug in operation, in which it calls
> governor start and set cpu_is_managed to 1, then the frequency change
> will go on and doesn't report error.
>
> The reason here is policy->cpu is always 0 if we use managed policy
> for all cpus. but we can't see which cpu's governor want's to
> start/stop in userspace goveror. we can only get the information from
> struct policy, but this policy doesn't include the exact cpu that
> wants to do governor start/stop.
>
>
> Any suggestions for this issue?
Hmm.. the problem is bigger than what you observed..
I am starting to cleanup userspace governor now and will cc you
for my patches. Please test them and give your Tested-by :)
Hi Ard!
As we've discussed today in IRC I'm sending you my asm based implementation for
RAID syndrome functions. I would be glad if you can compare this implementation
to intrinsics based one you are currently working on.
I don't post here my code for VFP/NEON context save/restore. People who are
interested may find patches developed by Ard on [1]. However, I'm using "fpu"
notation in these patches. Therefore, some changes to vfp/neon might be
necessary to make things working.
[1] https://patchwork.kernel.org/patch/2605041/
Thanks!
Vladimir Murzin
Each governor is suitable for different kernel configurations: the menu
governor suits better for a tickless system, while the ladder governor fits
better for a periodic timer tick system.
The Kconfig does not allow to [un]select a governor, thus both are compiled in
the kernel but the init order makes the menu governor to be the last one to be
registered, so becoming the default. The only way to switch back to the ladder
governor is to enable the sysfs governor switch in the kernel command line.
Because it seems nobody complained about this, the menu governor is used by
default most of the time on the system, having both governors is not really
necessary on a tickless system but there isn't a config option to disable one
or another governor.
Create a submenu for cpuidle and add a label for each governor, so we can see
the option in the menu config and enable/disable it.
The governors will be enabled depending on the CONFIG_NO_HZ option:
- If CONFIG_NO_HZ is set, then the menu governor is selected and the ladder
governor is optional, defaulting to 'yes'
- If CONFIG_NO_HZ is not set, then the ladder governor is selected and the
menu governor is optional, defaulting to 'yes'
Before this patch, the ARCH_NEEDS_CPU_IDLE_COUPLED option was wrongly not
depending on the CPU_IDLE and the Kconfig for OMAP / TEGRA was not checking
this dependency when setting the option.
With this patch, the ARCH_NEEDS_CPU_IDLE_COUPLED has been moved under the
CPU_IDLE option. The dependency has been fixed in the relevant arch's Kconfig.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
V3:
- Fixed Kconfig dependency between CPU_IDLE and ARCH_NEEDS_CPU_IDLE_COUPLED
V2:
- Set default values to 'yes' for the governors
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-tegra/Kconfig | 2 +-
drivers/cpuidle/Kconfig | 16 +++++++---------
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f49cd51..831e89e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -83,7 +83,7 @@ config ARCH_OMAP4
depends on ARCH_OMAP2PLUS
depends on ARCH_MULTI_V7
select ARCH_HAS_OPP
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if (SMP && CPU_IDLE)
select ARM_CPU_SUSPEND if PM
select ARM_ERRATA_720789
select ARM_GIC
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 84d72fc..04c6221 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -23,7 +23,7 @@ menu "NVIDIA Tegra options"
config ARCH_TEGRA_2x_SOC
bool "Enable support for Tegra20 family"
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if (SMP && CPU_IDLE)
select ARM_ERRATA_720789
select ARM_ERRATA_754327 if SMP
select ARM_ERRATA_764369 if SMP
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index c4cc27e..e997f15 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -1,7 +1,9 @@
-config CPU_IDLE
+menuconfig CPU_IDLE
bool "CPU idle PM support"
default y if ACPI || PPC_PSERIES
+ select CPU_IDLE_GOV_LADDER if (!NO_HZ && !NO_HZ_IDLE)
+ select CPU_IDLE_GOV_MENU if (NO_HZ || NO_HZ_IDLE)
help
CPU idle is a generic framework for supporting software-controlled
idle processor power management. It includes modular cross-platform
@@ -9,9 +11,10 @@ config CPU_IDLE
If you're using an ACPI-enabled platform, you should say Y here.
+if CPU_IDLE
+
config CPU_IDLE_MULTIPLE_DRIVERS
bool "Support multiple cpuidle drivers"
- depends on CPU_IDLE
default n
help
Allows the cpuidle framework to use different drivers for each CPU.
@@ -19,24 +22,19 @@ config CPU_IDLE_MULTIPLE_DRIVERS
states. If unsure say N.
config CPU_IDLE_GOV_LADDER
- bool
- depends on CPU_IDLE
+ bool "Ladder governor (for periodic timer tick)"
default y
config CPU_IDLE_GOV_MENU
- bool
- depends on CPU_IDLE && NO_HZ
+ bool "Menu governor (for tickless system)"
default y
config ARCH_NEEDS_CPU_IDLE_COUPLED
def_bool n
-if CPU_IDLE
-
config CPU_IDLE_CALXEDA
bool "CPU Idle Driver for Calxeda processors"
depends on ARCH_HIGHBANK
help
Select this to enable cpuidle on Calxeda processors.
-
endif
--
1.7.9.5
It seems I had to install more recent linaro image tools in order to
create a 13.05 SD card. Based on previous experience this was not a
complete surprise, but I had issues making linaro-media-create work on
my 12.04 system. After upgrading to 13.04 I found I had issues getting
the image tools to reinstall. Has anyone else run into this? Sorry for
not being more specific, but it was quite a bit of flailing before I got
back to something I could use.
Thanks,
-dl
=== Highlights ===
* Monday holiday! Took my first day off this year! :P
* Queued a bunch of community timekeeping patches for 3.10 and 3.11
* Sent my 3.10 queue to Thomas
* Lots of back and forth discussion on some community Xen patches
* Spent some time chasing a reported timekeeping regression in 3.9.4
* Reviewed Kahsim's slides and provided feedback, attended hangout for
more feedback.
* Reviewed blueprints and sent out weekly android upstreaming mail
* Worked a bit with DanielL on ramping up for drivers/clocksource timer
sub-maintainership
* Covered some linux-linaro process questions w/ MarkH
* Synced up with Deepak
=== Plans ===
* Send my 3.11 queue to tglx
* Probably handle a few remaining community items (Xen patches, 3.9.4
regression)
* Respond to Arnd's review of the ION patch & try to take some of the
issues to Rebecca
* Get back to Minchan on some of his private volatile range questions
* Start looking into generic sched_clock work being done in the community
=== Issues ===
* N/A