Hi all,
Here is another round of the mempressure cgroup. This time I dared to
remove the RFC tag. :)
In this revision:
- Addressed most of Kirill Shutemov's comments. I didn't bother
implementing per-level lists, though. It would needlessly complicate the
logic, and the gain would be only visible with lots of watchers (which
we don't have for our use-cases). But it is always an option to add the
feature;
- I've split the pach into two: 'shrinker' and 'levels' parts. While the
full-fledged userland shrinker is an interesting idea, we don't have any
users ready for it, so I won't advocate for it too much.
And since at least Kirill has some concerns about it, I don't want the
shrinker to block the pressure levels.
So, these are now separate. At some point, I'd like to both of them
merged, but if anything, let's discuss them separately;
- Rebased onto v3.8-rc2.
RFC v2 (http://lkml.org/lkml/2012/12/10/128):
- Added documentation, describes APIs and the purpose;
- Implemented shrinker interface, this is based on Andrew's idea and
supersedes my "balance" level idea;
- The shrinker interface comes with a stress-test utility, that is what
Andrew was also asking for. A simple app that we can run and see if the
thing works as expected;
- Added reclaimer's target_mem_cgroup handling;
- As promised, added support for multiple listeners, and fixed some other
comments on the previous RFC.
RFC v1 (http://lkml.org/lkml/2012/11/28/109)
--
Documentation/cgroups/mempressure.txt | 97 +++++
Documentation/cgroups/mempressure_test.c | 213 ++++++++++
include/linux/cgroup_subsys.h | 6 +
include/linux/vmstat.h | 11 +
init/Kconfig | 13 +
mm/Makefile | 1 +
mm/mempressure.c | 487 +++++++++++++++++++++++
mm/vmscan.c | 4 +
8 files changed, 832 insertions(+)
=== Highlights ===
* Pestered infrastructure and HR folks with tons of annoying questions
(thanks everyone! :)
* Got access to hackbox.linaro.org and as a temporary build system
* Got a test environment & cross compiler working
* Merged fixes from Tixy and Tushar to linaro.android branch
* Talked with Jakub and Zach about tree management plans
* Generated patches for alarm-dev compat_ioctl work & sent out to lkml
* Booked travel to Hong Kong for Connect
* Couple of community issues
=== Plans ===
* Get alarm-dev compat_ioctl work merged
* Sync w/ Serban on other compat_ioctl work
* Review Minchan's patches (still!)
* Merge a handful of community timekeeping patches & sync w/ tglx
=== Issues ===
* Still chasing some infrastructure issues
== Linus Walleij linusw ==
=== Highlights ===
* Handled the ux500 cpufreq and clksrc patches queued up
from Ulfs and Fabios side. Pushed Rafael Wysocki and
Sam Ortiz to obtain ACKs and after succeeding with that
send a pull request to the ARM SoC tree, Olof pulled it in.
* As explained last week working on AB8500 GPIO as it is a
roadblock for the multiplatform, as it is a SPARSE_IRQ
regression.
https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup
* Backmerged a set of patches for GPIO ranges into the internal
kernel tree to use as a base when preparing the new nice AB8500
driver.
* Had a report on the v3.8 not booting properly using DT for
some reason, maybe SPARSE_IRQ-related. Investigation
ongoing.
* Had a stab at the pinctrl and gpio subsystem backlog from the
mailing lists. Much remains, I have some week of backlog.
* Helped Lee a bit with advice & such ... the usual. Looked
into the charging patches a bit, looked at other stuff floating
by a bit. Both Lee & Fabio are doing great stuff at high speed
for ux500.
=== Plans ===
* First fix the AB8500 mess.
* Attack the remaining headers in arch/arm/mach-ux500
so we can move forward with multiplatform for v3.9.
* 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...
using an internal tracking sheet for this.
* Look into regmap. Try something out, get to know it.
=== Issues ===
* N/A
Thanks,
Linus Walleij
== Ulf Hansson ==
=== Highlights ===
* Spend two weeks of christmas holidays has in Sweden. I should be
full of energy right. :-)
Storage:
* Reviewing patches on mmc-list related to SDIO suspend/resume when
using SDIO IRQ as wakeup.
* Continue reviewing patches on mmc-list for Idle time BKOPS.
* Patches on mmc-list for fixing signal voltage switch procedure for
UHS mode seems ready. Acked and tested by different host driver
authors.
* Several patches sent for discussion for mmci host driver. Some has
been merged for 3.9.
Clk:
* Internal work done. Needed to be able to prepare a patchset to
implement abx500 clocks.
* Sent patchset for clk framework, to make an unsued clk unprepared at
late_init. Tested with a ux500 temporary patch.
=== Plans ===
Storage:
* Follow up on Idle time BKOPS patches on mmc list. Might help out in
sending a skeleton patch which the work can be based upon. Related to
runtime PM.
* Doing an overall analyse about the eMMC 4.5/4.6 features. Check what
can be considered finished, what needs further fixing and point out
the new features for which we should spend our focus on in Linaro
storage team.
* Push patches for mmci host driver to support for UHS cards.
* Push patches for mmci host driver to further extend the power
management support.
* Push patches for mmci host driver to add new features like CMD23
support and more.
Clk:
* Add support for new clk-types in abx500 clock driver for the ux500 platform.
* Send patch to let ux500 clks be unprepared at late_init. Depending
on the patches on the clk framework for this.
=== Issues ===
* Been trying for several month to get a hold of eMMC 4.5 device with
an SD-card adapter. Extremely important for the storage work in Linaro
to fully test eMMC4.5 features. Still no luck.
Kind regards
Ulf Hansson
==== Activity Summary ====
* Shawn Guo updated me on Runtime Size information for i.mx platform
* Additional 2 patch of ab8500 DT has been accepted by anton
* Working on MULTIPLATFORM enablement, presently looking into mach
folder segregation and populating include/linux/platform_data/ folder
accordingly
* Discussion with ShawnGuo on MULTIPLATFORM config.
==== Plan ====
* Continue Adding Multiplatform Config support
* Syncup with Linusw on Multiplatform Config
==== Issues ====
1 Day holiday
==== Activity Summary ====
* Completed "runtime size" data gathering across Vexpress-QEMU, i.MX
and U8500 platforms
* 3.7 is the kernel version verified across the said platforms
* Thanks to Shawn Guo for providing statistics on i.MX platform
* Google doc has been created and shared across relevant members
* Looking into adding Multiplatform Config support for U8500 platform
* Support for Rajagopal on Snowball board setup with tiny rootfs for
his testing/verification.
==== Plan ====
* Collect inputs from linusw on MultiPlatform work done so far and
continue to work
==== Issues ====
--- NA---
Hello Andrew, Russell,
Just resending this once again...
(Also rebased onto v3.8-rc2, and since there were some irqdomain changes,
I had to drop VIC changes from the series, and place the IRQ rerouting
code into the board code. But that is even better, so far we don't need it
anywhere else.)
Short description of the KDB/FIQ debugger:
The FIQ debugger is a facility that can be used to debug situations when
the kernel stuck in uninterruptable sections, e.g. the kernel infinitely
loops or deadlocked in an interrupt or with interrupts disabled. On some
development boards there is even a special NMI button, which is very
useful for debugging weird kernel hangs.
And FIQ is basically an NMI, it has a higher priority than IRQs, and upon
IRQ exception FIQs are not disabled. It is still possible to disable FIQs
(as well as some "NMIs" on other architectures), but via special means.
Old changelogs and a full rationale for these patches can be found here:
v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2
v6: http://lkml.org/lkml/2012/9/10/2
v7: http://lkml.org/lkml/2012/9/13/367
v8: http://lkml.org/lkml/2012/9/19/525
v9: http://lkml.org/lkml/2012/9/24/538
Thanks!
Anton
--
arch/arm/Kconfig | 19 ++++
arch/arm/include/asm/kgdb.h | 7 ++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 167 +---------------------------
arch/arm/kernel/entry-header.S | 170 +++++++++++++++++++++++++++++
arch/arm/kernel/kgdb_fiq.c | 118 ++++++++++++++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 55 ++++++++++
9 files changed, 459 insertions(+), 166 deletions(-)
=== Highlights ===
* Now a Linaro Employee!
* Fresh installed my client VM and personal netbook, got most of my work
environment set up (still some minor tweaking to do).
* Got local git trees re-generated
* Generated base testing VM image
* Ordered a build/test workstation for development
* Talked with Ryan & emailed with Jakub about tree management plans
* Generated a test branch updating the linaro.android tree to 3.8-rc2+
and sent it out for testing
* Generated a new blueprint for alarm-dev compat_ioctl work
=== Plans ===
* Continue tweaking work environment config
* Take a first pass swing at alarm-dev compat_ioctl work
* Apply/review Minchan's latest anon volatile patch
=== Issues ===
* Having difficulty getting access to hackbox.linaro.org
== Linus Walleij linusw ==
=== Highlights ===
* Sent pinctrl patches for v3.8 to Torvalds and he pulled them
in.
* Sent a first batch of updates for the -rc series for pinctrl as well
and Torvalds has pulled in these too.
* Grant has brough the pending GPIO patches upstream through
his tree.
* Inquiry into the state of CodeAurora's CoreSight patch set spurred
a fruitful discussion and the author has posted a first patch set.
* Working on multiplatform. So we have to take a step back:
When the platform was migrated to SPARSE_IRQ all drivers
should nominally have been converted to use irqdomain first.
This was not the case: the AB8500 GPIO driver was missed
(drivers/gpio/gpio-ab8500.c) So now it needs to be fixed.
However it turns out that this driver has a number of problems,
apart from being marked broken. So now I am working with
Patrice Chotard and Lee Jones to reshape this driver into
a proper pinctrl driver and put it into the pinctrl subsystem for
v3.9. Created a blueprint for this:
https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup
* Reviewed and back-merged a number of irqdomain and DT
patches to the internel v3.4 baseline while interacting with the
landing team. Now only AB8500 GPIO remains.
* Reviewed and back-merged the timer-based delay patches that
Fabio from the landing team has been working on. We have a
pending patch series for these, which will be sent to ARM SoC
ASAP.
* Reviewed and back-merged Fabios sync work for the DMA40
driver.
* Sent two fixes for the Nomadik post-v3.8 so it boots again.
* Worked a bit on U300 cleanups.
=== Plans ===
* First fix the AB8500 mess.
* Attack the remaining headers in arch/arm/mach-ux500
so we can move forward with multiplatform for v3.9.
* 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...
using an internal tracking sheet for this.
* Look into regmap. Try something out, get to know it.
=== Issues ===
* Some internal stir and vacation has affected productivity the
last month.
Thanks,
Linus Walleij
Hi everyone,
When building a kernel with the Linaro ARM toolchain I have two
seemingly simple questions, however I have been getting some very
different advice depending on who I talk to and what I read online,
study in gits etc. Hardware specific optimizations are confusing and
hard to test in a kernel since it such a multi-purpose conglomeration of
code. I just want to make sure I am using the correct general approach
before moving forward with trying things and testing. Our project is all
about testing and researching ways to increase kernel/Android
performance, so please don't reply with "just use an -O2 compilation and
forget about it" unless you have data you can provide that suggest that
this will give better performance than adding specific hardware
compilation flags.
Hopefully this is the right crowd to ask, wasn't sure if I should try
the kernel or Android list. I posted in the NEON list, but my message is
the only one from December! That leaves me with little hope there, so
we'll see how it goes here. If anyone can help me with part 1 or part 2,
I would be delighted!
Background:
* 3.4.x Android kernel
* Qualcomm APQ8064 quad core CPU (Cortex A15-like SoC with NEON/vfpv4
per core support).
* We are using the Linaro ARM toolchain 4.7.3 release 2012.11 on Linux
(arm-linux-gnueabihf).
Part 1) Which hardware and floating point compiler flags are
recommended/applicable for the above mentioned SoC when building kernel
itself?
-mtune=cortex-a15 (is this really doing anything for us in the
tool-chain's current state?)
Which -mfpu flag and other associated flags should we use in the Linaro
12.11 toolchain?
-mfpu=-neon-vfpv4
-mfpu=-vfpv4
-mfpu=-neon
-mvectorize-with-neon-quad
-funsafe-math-optimizations (is this required for -neon-vfpv4 and
-vfpv4 like we would use it for plain old -neon?)
Part 2) Next, which kernel Makefiles should be optimized using the
hardware specific flags from Q1? From my research thus far, this is our
current setup and we currently doing an -O2 build.
/Makefile:
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
-fno-delete-null-pointer-checks -mno-unaligned-access \
-march=armv7-a -mtune=cortex-a15 \
-fpredictive-commoning -fgcse-after-reload -ftree-vectorize \
-fipa-cp-clone -fsingle-precision-constant -pipe \
-funswitch-loops -floop-interchange \
-floop-strip-mine -floop-block
CFLAGS_MODULE = (BLANK, but some say we should have flags here)
AFLAGS_MODULE = (BLANK, but some say we should have flags here)
LDFLAGS_MODULE =
CFLAGS_KERNEL = (BLANK, but some say we should have flags here)
AFLAGS_KERNEL = (BLANK, but some say we should have flags here)
/arch/arm/Makefile
arch-$(CONFIG_CPU_32v7) :=-D__LINUX_ARM_ARCH__=7 $(call
cc-option,-mtune=cortex-a15 -march=armv7-a -mfpu=neon-vfpv4
-ftree-vectorize -funsafe-math-optimizations,-march=armv7-a
-Wa$(comma)-march=armv7-a)
/arch/arm/vfp/Makefile
KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=neon-vfpv4
-ftree-vectorize -funsafe-math-optimizations)
If you can give any advice, it would be greatly appreciated.
Thanks and have a Happy New Year!
