Hi All,
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
tasks.
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:
http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13342.html
Earlier discussions over this concept were done at last LPC:
http://summit.linuxplumbersconf.org/lpc-2012/meeting/90/lpc2012-sched-timer…
Module created for testing this behavior is present here:
http://git.linaro.org/gitweb?p=people/vireshk/module.git;a=summary
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
Setup:
-----
- ARM Vexpress TC2 - big.LITTLE CPU
- Core 0-1: A15, 2-4: A7
- rootfs: linaro-ubuntu-nano
Results:
-------
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
V2->V2-Resend
-------------
- Included timer migration patch in the same thread.
V1->V2
-----
- New SD_* macros removed now and earlier ones used
- sched_select_cpu() rewritten and it includes the check on current cpu's
idleness.
- 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
tejun.
- 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
saving
timer: hrtimer: Don't check idle_cpu() before calling
get_nohz_timer_target()
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(-)
--
1.7.12.rc2.18.g61b472e
Hi Guys,
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
or linaro-kernel
in cc, and we get replies to those mails, sometimes the mails from
outside people
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
from non-subscribers
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.
--
viresh
Hello,
After couple of iterations, android-build.linaro.org was updated to
authenticate against Linaro Login system. Please use your
login.linaro.org username (with @linaro.org suffix) and password to
login from now on. Personal jobs were also renamed to have
firstname.lastname prefix instead of Launchpad username. If you cannot
see your jobs, please contact me to check their state.
Below is interim progress report for completeness.
Thanks,
Paul
Begin forwarded message:
Date: Wed, 26 Jun 2013 22:43:07 +0300
From: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org>
To: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org>
Cc: linaro-android <linaro-android(a)lists.linaro.org>, Infrastructure
<infrastructure(a)linaro.org>, Linaro Validation
<linaro-validation(a)lists.linaro.org>, Philip Colmer
<philip.colmer(a)linaro.org> Subject: Re: [ANN] android-build.linaro.org
upgrade to Linaro Login Service
Hello,
On Wed, 26 Jun 2013 15:46:50 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:
> Hello,
>
> With Android releases out, I'd like to proceed with switchover of
> Android Build frontend authenticaton to Linaro Login. Estimated
> downtime is 2hrs. To minimize impact, I'm scheduling this for later
> evening UTC (around 8pm UTC). Let me know if you need access to a-b
> at that time (otherwise, upgrade is OKed by Vishal).
Upgrade went well, except that now it's not possible to create personal
builds. That's because login username is used to form created job
name, and with Linaro Login, username is first.last(a)linaro.org - that's
not valid as part of job name, and besides that, it's too long. Even if
I adhocly remapped it to first-last, it's still too long, and still
would required boring renaming of existing jobs.
Atlassian Crowd supports login aliases, Philip mentioned that it's
possible to create one, but I skipped doing that just for me, hoping
that it would be offered for all folks as part of git migration or
something, but that didn't happen. Well, I guess it's time to raise
that request now - going submit ITS ticket for this.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
There's a few warning that nobody noticed or cared until now:
[...]
Value requested for CONFIG_OABI_COMPAT not in final .config
Requested value: # CONFIG_OABI_COMPAT is not set
Actual value:
Value requested for CONFIG_MTD_CHAR not in final .config
Requested value: CONFIG_MTD_CHAR=y
Actual value:
Value requested for CONFIG_ENABLE_DEFAULT_TRACERS not in final .config
Requested value: CONFIG_ENABLE_DEFAULT_TRACERS=y
Actual value:
[...]
MTD_CHAR doesn't exist anymore.
ENABLE_DEFAULT_TRACERS depends on !GENERIC_TRACER
Is there any objection to drop both options from linaro-base.conf?
I'm not sure what to do with OABI_COMPAT.
Cheers,
--
Fathi Boudra
The maintenance on this server has been completed.
gerrit has been upgraded so it looks a little bit different now.
Also, the sign in process now only works with Linaro Login so clicking on
the "sign in" link no longer requires you to paste an OpenID URL. If you
are not authenticated with Crowd when you click on the "sign in" link, you
will be redirected to Crowd where you need to enter your *email address*
and your Linaro Login password.
If you have any problems with authentication, please email its(a)linaro.org.
Regards
Philip
Hi,
ci.linaro.org has switched the security realm from Launchpad OpenID to
Crowd SSO.
In practice, it means that authentication is using your regular
login/password from login.linaro.org service.
In addition, the project authorization strategy has been switched to
project-based matrix authorization strategy.
Those changes allows more permissions granularity at the project/job level.
It is now possible to create private/restricted jobs or allow
anonymous users to read your job configuration if you want.
Cheers,
--
Fathi Boudra
Builds and Baselines Manager | Release Manager
Linaro.org | Open source software for ARM SoCs
The recent dylan meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc
update from 13.04 to 13.06-1 seems to cause builds to break with errors
something like:
| cp: cannot create regular file
'/work/rdk/build-dylan-qemuarm/tmp/work/armv5te-rdk-linux-gnueabi/gcc-cross-initial/linaro-4.7-r2013.06-1/image/work/rdk/build-dylan-qemuarm/tmp/sysroots/x86_64-linux/usr/lib/armv5te-rdk-linux-gnueabi.gcc-cross-initial/gcc/arm-rdk-linux-gnueabi/4.7.3/include-fixed/limits.h':
No such file or directory
| ERROR: Function failed: do_install (see
/work/rdk/build-dylan-qemuarm/tmp/work/armv5te-rdk-linux-gnueabi/gcc-cross-initial/linaro-4.7-r2013.06-1/temp/log.do_install.11946
for further information)
Fix by updating BINV from 4.7.3 to 4.7.4 to match the change in gcc versions.
Signed-off-by: Andre McCurdy <andre.mccurdy(a)entropic.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc b/meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc
index b0bc7be..a5452be 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc
@@ -4,7 +4,7 @@ require gcc-linaro-common-4.7.inc
MMYY = "13.06"
RELEASE = "20${MMYY}-1"
PR = "r${RELEASE}"
-BINV = "4.7.3"
+BINV = "4.7.4"
FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-${PV}' ], d)}"
--
1.8.1.2
This e-mail and documents attached to this e-mail contain proprietary and/or confidential information of Entropic Communications. Such information is subject to copyright belonging to Entropic Communications. This e-mail is intended solely for the use of the individuals or entities to which it is addressed. If you are not the intended recipient of this e-mail, any distribution, copying or use of the contents of this e-mail and attachments is strictly prohibited and may be unlawful.