linaro-dev August 2013

linaro-dev@lists.linaro.org

44 participants
38 discussions

[PATCH V2 Resend 0/4] Create sched_select_cpu() and use it for workqueues and timers

by Viresh Kumar

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

11 years, 1 month

M0 and M3 patches in linaro toolchains

by Wookey

Debconf13 (last week) considered the matter of bare-metal cross-toolchains in Debian. Ideally we would have one toolchain source package from which the existing linux native compilers, and cross-compilers are built, including bare-metal cross-compilers. There is already mechanism for adding patches for particular gcc builds, so so long as the patch set is manageable and trackable, this would be nice, and futureproof, as eventually the patch set should just evaporate as it gets upstreamed. The alternative it to simply repack the existing linaro cross-toolchain sources, but them we get to keep doing that for new releases, and we have gratuitous extra copies of gcc sources and corresponding differences between A* and M* toolchains/versions. The linaro embedded toolchains (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are good, and work, both for M0 and M3. But building nominally the same thing from upstream gcc gets something where M3 works but M0 doesn't. Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. We peered at checkouts from linaro and upstream and tried to work out what the linaro patch-set for this toolchain is, and exactly where it branched off upstream, but it was confusing with a lot of noise due to version skew around some actually relevant changes. So, in order to work out if we can in fact build our bare-metal toolchains from the same sources as the existing toolchains we need to know what the actual patch-set you are maitaining looks like, and what is already upstreamed in which gcc branch/release and when the remaining patches will go upstream. Also what the 4.7 vs 4.8 status is. Knowing how this stuff is tracked might be even more useful over the longer term. Is there such info online somewhere? If not please elaborate. A mechanism for keeping the (newly-formed) Debian cross-compiler team sufficiently in the loop is probably what's needed in the longer term, unless this is all just about to get upstreamed anyway and the issue will soon become moot...? There was also discussion around the concept of making existing linux-arm cross-compilers, with M0 and M3 support included, and using spec-file jiggery-pokery to get them to DTRT for M* targets. This should be possible, but advice from anyone who's every actually tried on the gotchas would be good. cheers Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

11 years, 2 months

[PATCH RFC 0/2] PM / Hibernate: sysfs resume

by Sebastian Capella

Patchset related to hibernation resume: one enhancement to make the use of an existing file more general and one documentation update. Both patches are based on the 3.11-rc6 tag. This was tested on a Pandaboard with partial hibernation support, and compiled on x86. Further testing is needed on other platforms. Please let me know if you're able to verify this on any other systems. [PATCH RFC 1/2] PM / Hibernate: use name_to_dev_t to parse resume Use name_to_dev_t to parse the /sys/power/resume file making the syntax more flexible. It supports the previous use syntax and additionally can support other formats such as /dev/devicenode and UUID= formats. By changing /sys/debug/resume to accept the same syntax as the resume=device parameter, we can parse the resume=device in the initrd init script and use the resume device directly from the kernel command line. kernel/power/hibernate.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) [PATCH RFC 2/2] PM / Hibernate: add section for resume options This adds a small section to the swsusp.txt file to address the options for resuming. This comments on the manual resume option which is used when resorting to an initrd or initramfs for resuming. Resuming from late init is discussed later in the document, but it seemed appropriate to list them together. Documentation/power/swsusp.txt | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) Thanks, Sebastian

11 years, 3 months

LSK getting started

by Andy Green

Hi Mark - I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking(a)v3.10 LT patches on LSK basis work well (so far). I found this repo (it needs its ./description updating) https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=summary 1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android. I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences? 2) I saw the vexpress integration stuff from ARM LT was included already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition? 3) In our LT tree we patch mainline to remove all warnings coming with our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach? 4) Maybe this is too much thinking ahead, but shouldn't these lsk branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem. -Andy

11 years, 3 months

Does linux-linaro support kernel page size bigger than 4K?

by Xu, Qiang

Hi Linaro I am a software engineer from Qualcomm. I want to know that if Linaro can change its memory page size in kernel ? As my CPU is arm-v7, it supports 4k/64k/1M/16M page size translation, but in my linux kernel whose version is 2.6.38, the page size is always 4K, Do the linux-linaro support different page size in kernel?

11 years, 3 months

[PATCH v2 RFT 0/2] PM / Hibernate: sysfs resume

by Sebastian Capella

Patchset related to hibernation resume: one enhancement to make the use of an existing file more general and one documentation update. Both patches are based on the 3.11-rc6 tag. This was tested on a Pandaboard with partial hibernation support, and compiled on x86. Further testing is needed on other platforms. Please let me know if you're able to verify this on any other systems. [PATCH 1/2] PM / Hibernate: use name_to_dev_t to parse resume Use name_to_dev_t to parse the /sys/power/resume file making the syntax more flexible. It supports the previous use syntax and additionally can support other formats such as /dev/devicenode and UUID= formats. By changing /sys/debug/resume to accept the same syntax as the resume=device parameter, we can parse the resume=device in the initrd init script and use the resume device directly from the kernel command line. kernel/power/hibernate.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) [PATCH 2/2] PM / Hibernate: add section for resume options This adds a small section to the swsusp.txt file to address the options for resuming. This comments on the manual resume option which is used when resorting to an initrd or initramfs for resuming. Resuming from late init is discussed later in the document, but it seemed appropriate to list them together. Documentation/power/swsusp.txt | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) Changes in v2: -------------- * Added check for null return of kstrndup in hibernate.c Thanks, Sebastian

11 years, 3 months

Re: Can't boot my fresh build armv8 linaro kernel/

by Fathi Boudra

Hi, On 21 August 2013 12:46, Phi Debian <phi.debian(a)gmail.com> wrote: > Hi Fathi, > > Do you know someone who could help me progress on this, I am stuck > since Jul 12, well doing other things meanwhile :) > > I follow the receipe to download an boot and armv8 image, all that goes well. Which recipe? http://www.linaro.org/engineering/engineering-projects/armv8 http://releases.linaro.org/13.07/openembedded/aarch64 (build from source tab) > I then follow the receipe to build the latest kernel from git, it all > goes well, I got an Image along with a vmlinux (with debug info). Which tree? > I made the boot linux-system-foundation.axf file as descrived, I can > see that my kernel in in there > > $ strings -a linux-system-foundation.axf | grep phi > %s version %s (phi@hpfrcu82) (gcc version 4.8.2 20130624 ... > > > Then this is where I am stuck and can't find receipe how to boot this. > > I tried a brute > ./Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 --image > ./linux-system-foundation.axf --block-device ./rootfs.img > --network=nat I assume you tried our 13.07 release and it works fine, right? (to rule out an issue with your set up or the rootfs) > Where rootfs.img is the vexpress64-openembedded_lamp-armv8_20130719-403.img.gz > > Then I thougt 'may be' I got to populate the /boot in the rootfs.img > with my new kernel stuff, so I mounted it (losetp _offset, etc..) > placed > Image.gz-3.7.0-rc2+ > config-3.7.0-rc2+ > System.map-3.7.0-rc2+ > boot.axf > In there but still no joy This part isn't needed. > Is there someone at linaro who know how to boot a fresshly build > kernel, the receipe on the web must be incorect or out dated? linaro-dev mailing list is more appropriate. Cheers, Fathi

11 years, 3 months

CTS test result summary for Calender week 35 Linaro android TI-panda builds

by Soumya Basak

CTS results summary for Calender Week 35: > > Here is the cts test results summary on Lava dashboard Linaro android TI > Panda builds; > > > http://validation.linaro.org/dashboard/image-reports/linaro-android-member-… > > cts test result bundle stream : > > > http://validation.linaro.org/dashboard/streams/private/team/linaro/android-… > > Please refer to the link following link for complete CTS test result > report. > https://docs.google.com/a/linaro.org/file/d/0BwB-fT5LL31CUE5mTkhuY21ydHc/ed… > > > Thank You > Best Regards > Soumya Basak. >

11 years, 3 months

CTS test result summary for Calender week 35 Linaro android TI-panda builds

by Soumya Basak

CTS results summary for Calender Week 35: Here is the cts test results summary on Lava dashboard Linaro android TI Panda builds; http://validation.linaro.org/dashboard/image-reports/linaro-android-member-… cts test result bundle stream : http://validation.linaro.org/dashboard/streams/private/team/linaro/android-… Please refer to the attached cts tests result report. Thank You Best Regards Soumya Basak.

11 years, 3 months

Test Result Summary of Linaro Openembedded 13.08 release

by Soumya Basak

Linaro Openembedded 13.08 Release (Calender Week: 35): Here is the test result summary for Linaro Openembedded 13.08 release images. [1] Linaro Openembedded Minimal image (Column: AG) Result Spreadsheet: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdDhwR… [2] Linaro Openembedded Lamp image (Column: AG) Result Spreadsheet: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdDhwR… [3] Linaro Openembedded LEG-Java-ARMv8 image (Column: J) Result Spreadsheet: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdDhwR… Please refer to the result spreadsheet for details test results. Thank You Best Regards Soumya Basak.

11 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2013