This is V2 Resend of my sched_select_cpu() work. Resend because didn't got much
attention on V2. Including more guys now in cc :)
In order to save power, it would be useful to schedule work onto non-IDLE cpus
instead of waking up an IDLE one.
To achieve this, we need scheduler to guide kernel frameworks (like: timers &
workqueues) on which is the most preferred CPU that must be used for these
This patchset is about implementing this concept.
- The first patch adds sched_select_cpu() routine which returns the preferred
cpu which is non-idle.
- Second patch removes idle_cpu() calls from timer & hrtimer.
- Third patch is about adapting this change in workqueue framework.
- Fourth patch add migration capability in running timer
Earlier discussions over v1 can be found here:
Earlier discussions over this concept were done at last LPC:
Module created for testing this behavior is present here:
Following are the steps followed in test module:
1. Run single work on each cpu
2. This work will start a timer after x (tested with 10) jiffies of delay
3. Timer routine queues a work... (This may be called from idle or non-idle cpu)
and starts the same timer again STEP 3 is done for n number of times (i.e.
queuing n works, one after other)
4. All works will call a single routine, which will count following per cpu:
- Total works processed by a CPU
- Total works processed by a CPU, which are queued from it
- Total works processed by a CPU, which aren't queued from it
- ARM Vexpress TC2 - big.LITTLE CPU
- Core 0-1: A15, 2-4: A7
- rootfs: linaro-ubuntu-nano
Without Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1000, Own: 0, migrated: 0
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 1000, Own: 0, migrated: 0
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1000, Own: 0, migrated: 0
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 1000, Own: 0, migrated: 0
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 1000, Own: 0, migrated: 0
With Workqueue Modification, i.e. PATCH 3/3:
[ 2493.022335] Workqueue Analyser: works processsed by CPU0, Total: 1002, Own: 999, migrated: 3
[ 2493.047789] Workqueue Analyser: works processsed by CPU1, Total: 998, Own: 997, migrated: 1
[ 2493.072918] Workqueue Analyser: works processsed by CPU2, Total: 1013, Own: 996, migrated: 17
[ 2493.098576] Workqueue Analyser: works processsed by CPU3, Total: 998, Own: 993, migrated: 5
[ 2493.123702] Workqueue Analyser: works processsed by CPU4, Total: 989, Own: 987, migrated: 2
- Included timer migration patch in the same thread.
- New SD_* macros removed now and earlier ones used
- sched_select_cpu() rewritten and it includes the check on current cpu's
- cpu_idle() calls from timer and hrtimer removed now.
- Patch 2/3 from V1, removed as it doesn't apply to latest workqueue branch from
- CONFIG_MIGRATE_WQ removed and so is wq_select_cpu()
- sched_select_cpu() called only from __queue_work()
- got tejun/for-3.7 branch in my tree, before making workqueue changes.
Viresh Kumar (4):
sched: Create sched_select_cpu() to give preferred CPU for power
timer: hrtimer: Don't check idle_cpu() before calling
workqueue: Schedule work on non-idle cpu instead of current one
timer: Migrate running timer
include/linux/sched.h | 16 ++++++++++--
include/linux/timer.h | 2 ++
kernel/hrtimer.c | 2 +-
kernel/sched/core.c | 69 +++++++++++++++++++++++++++++++--------------------
kernel/timer.c | 50 ++++++++++++++++++++++---------------
kernel/workqueue.c | 4 +--
6 files changed, 91 insertions(+), 52 deletions(-)
I really don't know whom to direct this mail to and hence the wide spread.
Problem: When we send a mail to kernel mailing lists with linaro-dev
in cc, and we get replies to those mails, sometimes the mails from
doesn't reach us back on linaro mailing lists. And i hope the reason
behind that is
those people aren't subscribed to these lists.
For me it makes some sense to allow anyone to send mails to this list. Can that
request be considered?
I believe the idea behind blocking such use is for protecting against
spam mails, but
these mails/replies are really important and we certainly need them
delivered to us.
One solution (don't know if its possible) would be to monitor mails
and few people from Linaro can permit them on daily/hourly basis, so
that we don't get any
spam mails, but that would be a burden.
I have got some important updates for Android's Interactive Governor.
These are already sent to Todd Poyner for inclusion into AOSP and
we are awaiting a response.
These changes are important for ARM big LITTLE platforms which
want multiple instances of a governor to be available for a multi
Until then, we want these patches to land into linux-linaro release via
Below is what I did to generate this branch:
- Checked out: https://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=ref…
- Merged v3.10-rc2 into it (As I had some cpufreq core patches included here)
- Applied my patches (8) over it
I am not able to generate a formal PULL request using 'git request-pull'
as 3.10-rc2 is not yet there in your tree.
Please pull git://git.linaro.org/arm/big.LITTLE/mp.git
With this patch set we make use of cpu_do_idle to enter WFI mode,
many platform are not clearing the data buffer before WFI or
directly using the address instead of opcode. For the rest its good
to have a common approach.
Sanjay Singh Rawat (8):
ARM: EXYNOS: use generic cpu idle function for wfi
ARM: RealView: use generic cpu idle function for wfi
ARM: SPEAr: use generic cpu idle function for wfi
ARM: vexpress: use generic cpu idle function for wfi
ARM: zynq: use generic cpu idle function for wfi
ARM: ux500: use generic cpu idle function for wfi
ARM: msm: use generic cpu idle function for wfi
ARM: PRIMA2: use generic cpu idle function for wfi
arch/arm/mach-exynos/hotplug.c | 9 ++-------
arch/arm/mach-msm/hotplug.c | 9 ++-------
arch/arm/mach-prima2/hotplug.c | 4 ++--
arch/arm/mach-realview/hotplug.c | 9 ++-------
arch/arm/mach-spear/hotplug.c | 3 ++-
arch/arm/mach-ux500/hotplug.c | 5 +++--
arch/arm/mach-vexpress/hotplug.c | 3 ++-
arch/arm/mach-zynq/hotplug.c | 4 ++--
8 files changed, 17 insertions(+), 29 deletions(-)
also cc linaro kernel
This patch will forward target residency information from the arm_big_little
driver to mcpm.
If multiple powerdown states are used, the vendor specific code will need a way to distinguish the intended c-state information.
I do not have TC2 hardware to verify this. Would someone be able to help
verify this change on TC2?
Sebastian Capella (1):
cpuidle: arm_big_little: route target residency to mcpm
drivers/cpuidle/arm_big_little.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
This wiki page:
- is now tracking the linux-linaro kernel rebuilds for 13.05.
v3.9 release based linux-linaro-core-tracking (llct) rebuild has been
published, the tag is llct-20130502.0 . The 13.05 linux-linaro release
will be v3.10-rc3 based, but let's do one more v3.9 based kernel not to
miss the v3.9 release.
The next step is:
May 06: ll rebuild based on llct-20130502.0.
The last llct update for this cycle is scheduled on May 21,
The last linux-linaro update for this cycle is scheduled on May 23.
May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed
after this date).
This series patch begins the process of splitting ohci-platform up
into independent driver modules and add a name for the platform-private field.
Patch 1/2 separate ohci-platform into independent driver modules.
Patch 2/2 adds an ohci->priv field for private use by OHCI platform drivers.
Manjunath Goudar (2):
USB: OHCI: make ohci-platform a separate driver
USB: OHCI: add a name for the platform-private field
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ohci-hcd.c | 6 +--
drivers/usb/host/ohci-platform.c | 88 ++++++++++++++++++--------------------
drivers/usb/host/ohci.h | 3 ++
5 files changed, 47 insertions(+), 53 deletions(-)
This series of patches begins the process of splitting ohci-hcd up into
a core library module and independent pci driver modules.
Patch 1/3 prepares the way by exporting a few functions from ohci-hcd
and adding a new mechanism for platform-specific drivers to initialize
their hc_driver structures. This deserves to be done in the core
because almost all of the entries in these structures are pure
boilerplate -- practically none of the drivers need to override more
than three of the standard core values.
Change from V7 to V8
ohci_hcd_init() is called by ohci_setup() to make generic ohci
initialization in all ohci drivers.
Patch 2/3 is part of separating the ohci pci host controller
driver from ohci-hcd host code.
Moved sb800_prefetch() function from ohci-pci.c to pci-quirks.c file
and EXPORTed, this is part of the effort to move the ohci pci related
code to generic pci code.
Change from V7 to V8
Patch 3/3 separate out ohci-pci into independent driver modules.
Change from V7 to V8
USB_OHCI_HCD_PCI symbol no longer dependence on STB03xxx, PPC_MPC52xx and
USB_OHCI_HCD_PPC_OF that's what removed.
Manjunath Goudar (3):
USB: OHCI: prepare to make ohci-hcd a library module
USB: OHCI: Generic changes to make ohci-pci a separate driver
USB: OHCI: make ohci-pci a separate driver
drivers/usb/host/Kconfig | 6 +-
drivers/usb/host/Makefile | 3 +
drivers/usb/host/ohci-hcd.c | 134 ++++++++++++++++++++++++++----------
drivers/usb/host/ohci-hub.c | 1 -
drivers/usb/host/ohci-pci.c | 151 ++++++++++++-----------------------------
drivers/usb/host/ohci-q.c | 6 +-
drivers/usb/host/ohci.h | 17 +++++
drivers/usb/host/pci-quirks.c | 13 ++++
drivers/usb/host/pci-quirks.h | 2 +
9 files changed, 184 insertions(+), 149 deletions(-)