=== Highlights ===
* Reviewed the current android common/android-3.3 branch and pulled out
updates to the already upstream items in staging, and submitted them to
Greg for staging-next, so they'll be ready when the 3.4 window opens
soon. These efforts got some positive press here:
http://www.phoronix.com/scan.php?page=news_item&px=MTA2ODA
* Discussed androidization topic branch for Andrey's linaro linux
kernel. Sent the current AOSP 3.3 branch to Andrey for the 12.3 release.
* Reworked my range-tree code for fadvise volatile to use a rbtree for
better balancing & to simplify the code. Also spent time trying to work
out dual-list locking issues.
* Got pulled into some community timekeeping bug reports, I've tried,
but haven't been able to reproduce yet.
* Verified PaulW's omap resume fix patch
* Got pulled into a sched_clock issue. Reviewed and acked a fix on lkml.
* Updated my rtc, timekeeping and clocksource queues for 3.4.
=== Plans ===
* Continue implementing solution to fadvise volatile dual-list locking
issue
* Likely a few other timekeeping issues & trying to make sure everything
I have pending for 3.4 is queued upstream.
=== Issues ===
* NA
== Arnd Bergmann <arnd> ==
=== Highlights ===
* Merged tons of patches into the arm-soc tree, then handed over to Olof for
the meantime but will probably take over again for the merge window
* Sent out status of the arm-soc tree report for the 3.4 merge window
* Worked with Jason Cooper to get Kirkwood DT conversion started
* Worked with Roland Stigge to get him established as lpc32xx maintainer
and get his code for that platform in, he will work on lpc32xx DT stuff
in the v3.5 cycle.
* Worked with Alan Ott and Mathieu Poirier to start getting my randconfig
patches merged.
* Worked with Niklas Hernaeus and Lee Jones to speed up the ux500 DT conversion.
* Code review: pxa/mmp DT patches, bmp085 driver, at91, dreamplug, ...
=== Plans ===
* Keep watching over various DT conversions
* Dig out my old series for inb/outb elimination and get that
into shape for -next after the merge window
== Linus Walleij linusw ==
=== Highlights ===
* Merged pin control patches from Stephen Warren,
finalizing the API transition.
* Sent a patch series converting U300 over to using
pin control.
* Updated pinctrl blueprints, created work for myself by
opening a ux500 pinctrl transition blueprint.
* Sent some AB8500 updates including AB8505 support
to Sam for MFD.
* Looking over some other internal patches, particularly
patches touching the core kernel outside our own drivers,
posting a cpufreq-ondemand patch today.
* Discussed dmaengine.
* Discussed internal alignment of Linaro activities for
two issues as requested by Andrea.
=== Plans ===
* Test the U9540 patches on real hardware and rework
as outlined by Arnd.
* Accumulate pinctrl patches for kernel v3.4 merge
window.
* Work on the blueprint for ux500 pinctrl.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
like
- Ux500 clocks
- the HWMON stuff.
=== Issues ===
* None!
Thanks,
Linus Walleij
Hi there,
There's considerable activity in the subject of the scheduler lately and how to
adapt it to the peculiarities of the new class of hardware coming out lately,
like the big.LITTLE class of devices from a number of manufacturers.
The platforms that Linux runs are very diverse, and run differing workloads.
For example most consumer devices will very likely run something like Android,
with common use cases such as audio and/or video playback. Methods to achieve
lower power consumption using a power aware scheduler are under investigation.
Similarly for server applications, or VM hosting, the behavior of the scheduler
shouldn't have adverse performance implications; any power saving on top of that
would be a welcome improvement.
The current issue is that scheduler development is not easily shared between
developers. Each developer has their own 'itch', be it Android use cases, server
workloads, VM, etc. The risk is high of optimizing for one's own use case and
causing severe degradation on most other use cases.
One way to fix this problem would be the development of a method with which one
could perform a given use-case workload in a host, record the activity in a
interchangeable portable trace format file, and then play it back on another
host via a playback application that will generate an approximately similar load
which was observed during recording.
The way that the two hosts respond under the same load generated by the playback
application can be compared, so that the performance of the two scheduler implementations
measured in various metrics (like performance, power consumption etc.) can be
evaluated.
The fidelity of the this approximation is of great importance but it is debatable
if it is possible to have a fully identical load generated, since details of the hosts
might differ in such a way that such a thing is impossible.
I believe that it should be possible at least to simulate a purely CPU load, and the
blocking behavior of tasks, in such a way that it would result in scheduler decisions
that can be compared and shared among developers.
The recording part I believe can be handled by the kernel's tracing infrastructure,
either by using the existing tracepoints, or need be adding more; possibly even
creating a new tracer solely for this purpose.
Since some applications can adapt their behavior according to insufficient system
resources (think media players that can drop frames for example), I think it would
be beneficial to record such events to the same trace file.
The trace file should have a portable format so that it can be freely shared between
developers. An ASCII format like we currently use should be OK, as long as it
doesn't cause too much of an effect during execution of the recording.
The playback application can be implemented via two ways.
One way, which is the LinSched way would be to have the full scheduler implementation
compiled as part of said application, and use application specific methods to evaluate
performance. While this will work, it won't allow comparison of the two hosts in a meaningful
manner.
For both scheduler and platform evaluation, the playback application will generate the load
on the running host by simulating the source host's recorded work load session.
That means emulating process activity like forks, thread spawning, blocking on resources
etc. It is not clear to me yet if that's possible without using some kind of kernel
level helper module, but not requiring such is desirable.
Since one would have the full trace of scheduling activity: past, present and future; there would
be the possibility of generating a perfect schedule (as defined by best performance, or best
power consumption), and use it as a yardstick of evaluation against the actual scheduler.
Comparing the results, you would get an estimate of the best case improvement that could be
achieved if the ideal scheduler existed.
I know this is a bit long, but I hope this can be a basis of thinking on how to go about
developing this.
Regards
-- Pantelis
== Highlights ==
* Debugged cgroups inaccuracy when calculating memory usage,
prepared a hack that fixes the issue, sent an RFC. A proper fix
needs to be implemented though;
* Reviewing/comparing various low memory notifications:
the one from Minchan Kim (http://lwn.net/Articles/475791/), Nokia's
memory meter (http://lkml.org/lkml/2012/1/4/208) and vmevent
(http://lkml.org/lkml/2012/1/17/370). Feature and reception-wise
VM event framework looks like a winner;
* Tried vmevents notifications framework, prepared a few fixes;
* Added two-way notifications to vmevents;
* Added vmevents support for the ulmkd.
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
We are know that the OMAP4460's PMU is buggy, which loses PMU interrupt always.
But I do not know what the real bug is, the HW bug or Software bug?
What the bug is?
Could some one give a point?
Kyler Zhang
== Deepak Saxena <dsaxena> ==
=== Highlights ===
* Lots of catching up on emails from pre-ELC
* 1-on-1's
* Discussions on kernel upstreaming and roadmap process
* Review of big.LITTLE Task Migration test plan
=== Plans ===
* Work on kernel wiki page updates
* 1-on-1's, sub-team meetings
* Working on roadmap cards
* Start outline of porting guide that was discussed @ Connect
* Continue looking at kernel upstreaming and roadmap process
* Start outline of member's update on how kernel development process
differs from traditional software development.
* Dive deeper into big.LITTLE switcher project
=== Issues ===
*** I have lost all wiki access permissions (can't edit or create pages, ***
*** can't acces /Internal). RT ticket filed last week but no progress. ***
=== Travel/Time Off ===
* Taking Monday March 12th mostly off, might be online parts of the day
* Possible off May 4-10th.
* Connect Q2
>Hi all,
>We are know that the OMAP4460's PMU is buggy, which loses PMU interrupt always.
>But I do not know what the real bug is, the HW bug or Software bug?
>What the bug is?
Kyler,
This is a hardware problem in the ARM core. It is not specific to the
4460, for instance it also occurs in the 4430 (and presumably non-TI
SoCs). The result of this bug is that PMU counter overflow interrupts
are sometimes lost. The affect can be reduced by paralleling PMU
counters, but this only reduces the problem statistically somewhat.
There is no complete workaround.
The problem is described in ARM errata, but I do not believe that
information is generally available. I think it can be found on a
Freescale site though. I suggest googling for ARM errata 628216.
I believe this will be fixed in a future iteration of the design, but I
do not know when this will be released.
-dl
David Long
Linaro
=== Device Tree ===
* Sent the full series (20 patches) adding DT support for IMX audio.
- Covert audmux driver to a platform driver and move it into ASoC
- Consolidate PowerPC SSI driver and make it work for IMX
- Add imx-sgtl5000 machine driver (DT only)
=== Misc ===
* Reviewed ANATOP MFD and Regulator series (v7) from Paul Liu
--
Regards,
Shawn
== Niklas Hernaeus <nhe> ==
=== General activity ===
* Made the initial DT system to build and boot reliably.
* Sent out a patch for this initial DT system.
/nhe
