linaro-kernel February 2012

linaro-kernel@lists.linaro.org

33 participants
26 discussions

February 2012 Kernel Release

by Deepak Saxena

The Linaro Kernel Working Group (KWG) and the Linaro Platform Group are excited to announce the availability our February 2012 development snapshot: linux-linaro-3.3-rc3-2012.02-1 As the word "snapshot" implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. We are excited about our first -rc based kernel as we move to a new process that will provide early access to more bleeding edge features on member-supported LEBs. The source tarball is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/linux-linar… The kernel sources can also be accessed using git at: git://git.linaro.org/people/ynk/linux-linaro-tracking.git tag: linux-linaro-3.3-rc3-2012.02-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.3-rc3 - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG * thermal_cpu_cooling patch set from the power management WG * irq_domain patch set from Grant L. (cherry-picked from linux-next) * Fix for https://bugs.launchpad.net/bugs/918412 * Basic device tree board support for supported ARM boards (comes from linux-linaro-3.1) * sched: Ensure cpu_power periodic update (Vincent G.) * ARM: kprobes: work around build errors (Arnd B.) * usb: ehci: make HC see up-to-date qh/qtd descriptors ASAP (Ming L.) * Perf: Fallback to /bin/more if less is not found for perf pager (Avik S.) A full change log against the 3.3-rc3 release is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/CHANGELOG-l… High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/

12 years, 2 months

[PATCH RFC 0/4] Scheduler idle notifiers and users

by Anton Vorontsov

Hi all, For some drivers we need to know when scheduler is idling. The most straightforward way is to gracefully hook into the idle loop. On x86 there are "CPU idle" notifiers in the inner idle loop, but scheduler idle notifiers are different. These notifiers do not run on every invocation/exit from cpuidle, instead they used to notify about scheduler state changes, not HW states. In other words, CPU idle notifiers work inside while(!need_resched()) loop (nested into idle loop), while scheduler idle notifier work outside of the loop. The first two patches consolidate scheduler idle entry/exit points, and converts architectures to this new API. The third patch is a new cpufreq governor, the commit message briefly describes it. The fourth patch is another user of the notifiers, a trivial one. Thanks, p.s. For the reference, the old discussion about CPU/PM idle notifiers: http://lkml.org/lkml/2011/6/27/391 -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 2 months

[Activity] (Niklas Hernaeus) 2012-02-13 - 2012-02-17

by Niklas Hernaeus

== Niklas Hernaeus <nhe> == === General activity === * Changing snowball version to new. This implies using different tools. * Due to new tools, upgrading workstation to new ubuntu. * Sorted out git.linaro.org problems. Thanks Lee Jones. /nhe

12 years, 2 months

[ACTIVITY] (Anton Vorontsov) 2012-02-13 - 2012-02-17

by Anton Vorontsov

== Highlights == * Further work on familiarizing with the scheduler code. * Built and tried cpufreq-bench, but the suite reported that it'll take more then 6 hours to complete. I hope it's some bug in the cpufreq-bench, but didn't investigate it yet. * Got some notes/concerns regarding idea of moving LMK to the userland. The problem is that we should make sure that LMK would not need any new allocations, which seems nearly impossible in JVM. The idea to solve the issue would be to move killer process into the C code (as a daemon), and then revert Activity Manager to handle oom_adj. Upon low-memory event, the killer would just read pid's oom_adj. This will be good for a proof-of-concept thing (and as a drop-in replacement for the LMK kernel driver), but for production, we might want Activity Manager to keep process list in a shared memory (+ maybe liburcu for efficiency). This whole scheme seems even better then having everything in Java (as we won't need cgroups/low-memory-notifiers bindings). -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 2 months

[ACTIVITY] (Anton Vorontsov) 2012-02-06 - 2012-02-10

by Anton Vorontsov

== Highlights == * Submitted interactive cpufreq governor, got a lot of feedback. Mostly about cpufreq in general, and that we should make scheduler more PM-aware instead on making cpufreq itself scheduler-state aware. Fiddling with the scheduler is surely a lot of fun, so I started looking into entity load-tracking re-work patches by Paul Turner @ Google. As Peter Zijlstra says, these patches should be a good start to add avg runtime per cpu. * Further work on a patchset that fixes various task->mm handling mistakes. More abusers found and fixed. (This is started as a LMK cleanup, but as it appears a lot of other code in the kernel has the same bugs.) * Several LMK fixes were accepted into -staging. -- Anton Vorontsov Email: cbouatmailru(a)gmail.com

12 years, 2 months

[ACTIVITY] (John Stultz) Feb 11-17

by John Stultz

=== Highlights === * Rebased the 3.2 Androidization patches from Andy Green onto 3.3-rc3 and provided them to Andrey for the 12.2 release. * Worked to get Rafael's wakelock patches into a git tree for testing. Unfortunately the patches have been under quite a bit of churn on the list, so I asked Rafael for a git tree to pull from, but he's not yet responded. * Pinged tglx on my patch queues for 3.4, and he pulled them in. * Spent some time trying to get a test platform working to play with Rafael's wakelock patches. So far there seems to be an issue getting the panda board to notice wake-events after suspending. * Finished a first rough draft summarizing Android upstreaming meeting from last week. The hope is to publish it to lwn once complete. * Tried to address a number of comments on the fadvise volatile patches. Integrated a few fixes to issues noticed by reviewers, and proposed using a different interface if folks feel fadvise isn't appropriate. Found an ugly locking issue I need to solve. * Handled some Android-subteam items. === Plans === * Finish summary writeup and send to lwn * Read over other fadvises discussions going on, and review interval kinterval tree implementation sent out by Andrea Righi. * Read more on the pagecache code, and try to take another pass at fadvise volatile code. === Issues === * NA

12 years, 3 months

[ACTIVITY][weekly][linaro] (Dave Martin) 2012-01-30 - 2012-02-17

by Dave Martin

[ACTIVITY][weekly][linaro] (Dave Martin) 2012-01-30 - 2012-02-17 == Dave Martin <dmart> == === Activity Summary === * big.LITTLE switcher bringup on the ARM model to be delivered to Linaro (builds; mostly, but not completely, working) * Linaro Connect * Started hacking some patches to enter the kernel in HYP mode to allow the kernel to install its own hypervisor code at run-time -- potentially of interest to the big.LITTLE and KVM folks. -> git://git.linaro.org/people/dmart/linux-3-arm.git arm/hyp-entry+zImage-bounce-hacks (zImage decompressor runs mostly in SVC mode, appears to work, but the zImage hacks are fundamentally flawed and may not work on real hardware) -> git://git.linaro.org/people/dmart/linux-3-arm.git arm/hyp-entry+lpae (zImage decompressor runs natively in hyp mode -- currently extremely incomplete and out of sync with the other branches) -> git://git.linaro.org/people/dmart/boot-wrapper.git hyp-entry/fixes (fixes on top of Rusty's boot-wrapper required for actually testing the above branches on the model) This work is not posted upstream yet: the plan is to get a sane implementation and a reasonably clean patch series before posting an upstream RFC. === Plans === * Sync the various arm/hyp-entry branches and cleanly separate the main kernel stuff from the zImage decompressor stuff * Address the various comments received so far. * Modify the in-kernel hypervisor stub just to provide a raw "jump to this address in hyp mode" call instead of a cooked "set hypervisor vectors" call. This is closer to Christoffer Dall's existing implementation for KVM, and is both simpler and more flexible than my current approach. * Clean up main kernel patches and post upstream RFC. * Get the zImage decompressor working in hyp mode; post for review. * Draft initial specification for the big.LITTLE implementation details within Linaro, and flesh out the blueprint. * Finish debugging the GNU-ised ARM switcher on the A15+A7 model. === Work Items === no update === Absences === none planned yet

12 years, 3 months

SPI driver issue in Linux kernel3.0.8 ~ - Ask Linaro

by Michael Opdenacker

Greetings, There's a question on Ask Linaro, about a driver that worked in 2.6.35, but stopped working in 3.0.8: http://ask.linaro.org/questions/727/spi-driver-issue-in-linux-kernel308 Don't hesitate to share any advise and tips with the guy, Thanks in advance, Cheers, Michael. -- Michael Opdenacker - Community Manager Linaro, http://linaro.org Phone: +33 484 253 396 IRC: 'opm' in #linaro on irc.freenode.net

12 years, 3 months

[ACTIVITY] (John Stultz) Feb 6-10

by john stultz

=== Highlights === * Attended Linaro Connect. Now a bit exhausted. :) * Presented on merge_config.sh script. Interesting discussion around how even within linaro we have a variety of build systems with which we will have to integrate the concept of config fragments. The question of who maintains the fragments is still somewhat open, but hopefully we can centralize their location in the linaro kernel source maintained by Andrey. Two interesting suggestions were to have something like a source command in config fragments, as well as some commented out annotation in the resulting config. Will have to look into these in the future. * Dropped by the Android workgroup room and worked with Vishal and Amit on the Android team to get the origen fb console working with software rendering under Android. It was great to go into the Android room and get really useful help in working out what the problems were. This was really useful for Demo Friday, and great example of the benefit of attending Linaro Connect. * Had some discussions as well as attended talks about plans for Android's ion infrastructure. There seems to be a fair amount of community interest in it, but from the Google folks' comments, it seems like it may have a fair amount of churn in the future, so it may not be best to upstream it yet. Having some point for community discourse and collaboration (if not a centralized merge point) is needed. * Re-sent android-alarm driver to GregKH for staging, as he had some last minute requests on minor patch ordering issues. * Resolved the last few bugs I could trigger with my range-tree implementation of fadvise volatile code. Sent out to lkml for review. So far only minor comments, but I did get some mail today on a different but related fadvise effort that is also using range data. * Attended the Android upstreaming effort community face to face meeting organized by Tim Bird. It was ~4 hours and covered a lot of material. Very positive interaction overall with the Google folks. They seem to be in agreement with most of our approaches, and where they disagreed they were not dismissive, and were open to us still prototyping and trying to convince them otherwise. * Demoed the origen board running Android on a vanilla linus' HEAD 3.3-rc kernel with only two minor patches. Repeated myself endlessly to probably everyone. === Plans === * Need to summarize and organize my thoughts from the week, and catch up on some Android Kernel Subteam items. * Plan on closer review of Rafael's wakelock patches that were sent out and try to integrate them with the android alarm timers work in staging. * Read over other fadvises discussions going on, and review interval kinterval tree implementation sent out by Andrea Righi. * Take another pass at fadvise volatile code. * Ping tglx on 3.4 queue. === Issues === * NA

12 years, 3 months

[PATCH] staging: android/lowmemorykiller: Don't grab tasklist_lock

by Anton Vorontsov

Grabbing tasklist_lock has its disadvantages, i.e. it blocks process creation and destruction. If there are lots of processes, blocking doesn't sound as a great idea. For LMK, it is sufficient to surround tasks list traverse loop with rcu_read_{,un}lock() pair. Suggested-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- Also thanks to Eric and Paul for the ideas. drivers/staging/android/lowmemorykiller.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index 2d8d2b7..b3ade2f 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -34,6 +34,7 @@ #include <linux/mm.h> #include <linux/oom.h> #include <linux/sched.h> +#include <linux/rcupdate.h> #include <linux/profile.h> #include <linux/notifier.h> @@ -132,7 +133,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) } selected_oom_adj = min_adj; - read_lock(&tasklist_lock); + rcu_read_lock(); for_each_process(p) { struct mm_struct *mm; struct signal_struct *sig; @@ -185,7 +186,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) } lowmem_print(4, "lowmem_shrink %lu, %x, return %d\n", sc->nr_to_scan, sc->gfp_mask, rem); - read_unlock(&tasklist_lock); + rcu_read_unlock(); return rem; } -- 1.7.7.6

12 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel February 2012