linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

by Anton Vorontsov

Hi all, This is the third RFC. As suggested by Minchan Kim, the API is much simplified now (comparing to vmevent_fd): - As well as Minchan, KOSAKI Motohiro didn't like the timers, so the timers are gone now; - Pekka Enberg didn't like the complex attributes matching code, and so it is no longer there; - Nobody liked the raw vmstat attributes, and so they were eliminated too. But, conceptually, it is the exactly the same approach as in v2: three discrete levels of the pressure -- low, medium and oom. The levels are based on the reclaimer inefficiency index as proposed by Mel Gorman, but userland does not see the raw index values. The description why I moved away from reporting the raw 'reclaimer inefficiency index' can be found in v2: http://lkml.org/lkml/2012/10/22/177 While the new API is very simple, it is still extensible (i.e. versioned). As there are a lot of drastic changes in the API itself, I decided to just add a new files along with vmevent, it is much easier to review it this way (I can prepare a separate patch that removes vmevent files, if we care to preserve the history through the vmevent tree). Thanks, Anton. -- Documentation/sysctl/vm.txt | 47 +++++ arch/x86/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 2 + include/linux/vmpressure.h | 128 ++++++++++++ kernel/sys_ni.c | 1 + kernel/sysctl.c | 31 +++ mm/Kconfig | 13 ++ mm/Makefile | 1 + mm/vmpressure.c | 231 +++++++++++++++++++++ mm/vmscan.c | 5 + tools/testing/vmpressure/.gitignore | 1 + tools/testing/vmpressure/Makefile | 30 +++ tools/testing/vmpressure/vmpressure-test.c | 93 +++++++++ 13 files changed, 584 insertions(+)

12 years, 7 months

[ACTIVITY] (Rajanikanth H V) 2012-11-19 to 2012-11-23

by Rajanikanth HV

==== Activity Summary ==== - Finalized the blueprint based on detailed requirements captured Note: i.MX is the new platform added to analysis list - Collected build time kernel image and driver data size information across the required platform: - Was blocked on collecting runtime kernel and modules sizes information on u8500 platform, as i found boot time issue on 3.7-rc6 version: Ethernet driver is failing to initialize, debugging further i found that regulator for smsc911x chip is not being turned on. Note: Did not observe above said issue on 3.6, - Implemented review comments from "francesco lavra" regarding ab8500 mfd BM devices patches, manually rebased(against 3.7-rc6), tested and communicated the patchset to ML's. - Anton has merged my previous patch set(thanks to anton), preparing delta patches with the latest one ==== Plan ==== - Communicate delta patchs for ab8500 mfd to anton - Continue to gather and analyze build and runtime size information - Discuss and consolidate with arnd on the zImage size data ontained ==== Issues ==== 0.5 day holiday

12 years, 7 months

[ACTIVITY] (Anton Vorontsov) 2012-11-12 - 2012-11-23

by Anton Vorontsov

== Highlights == * While cgroups discussion was ongoing, I finally found some time to revive my Android emulator setup and validate stock out of memory killer. Running with in-kernel LMK completely disabled (and using ulmkd instead) I could trigger OOMK by large instant allocations, and the OOMK was always choosing the right target (i.e. w/ the correct oom_adj). So it behaves exactly as expected, and I could not reproduce any rumoured issues with it; * Started work on mempressure cgroup and per-thread vmpressure. Basically, this is 'everything from scratch', again. :( This will surely slip v3.8, although hopefully I'll have a draft/RFC to show this week; * Resent KDB/FIQ/Kiosk patches, this time to Andrew Morton.

12 years, 7 months

[ACTIVITY] (Linus Walleij) 2012-11-20 - 2012-11-23

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Intense activity on pinctrl and gpio trees, also sending yet another round of pull requests for fixes to Torvalds for GPIO. * Switched the U300 over to use the GPIO ranges. Discovered more issues with the solution and solved them with another 10 patches to the related code and drivers. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo… * Finalized my GPIO patch stack and sent of a pull request to Grant so he can funnel this to Torvalds for kernel v3.8. * Discussed the status of the CW1200 driver in a lot of private mails. * Acked a plethora of patches for the removal of __devinit * Send clock patches for the Integrator/IM-PD1 to Mike Turquette, he merged them. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9 or so. (Make no promises, make no commitments...) * 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 === * The GPIO range blueprint got escalated above the single zImage work due to influx from the community. Since contribuitors drive the process this happens... It was work that was on our blueprint list, but we could not control the priority of execution. I think this is normal but it needs to be reported and noted. Thanks, Linus Walleij

12 years, 7 months

[PATCH resend 0/7] KDB: Kiosk (reduced capabilities) mode

by Anton Vorontsov

Hi Andrew, Jason, And yet another set that folks seem to be too busy to look into. :) The rationale for the series is this: This patchset implements "kiosk" mode for KDB debugger. The mode reduces kdb features, so that it is no longer possible to leak sensitive data via the debugger, and not possible to change program flow in a predefined manner by an ordinary user. The root can control the capability. It is useful on phones with an easy access to a debugger console (e.g. thru a headphone mini-jack), or on a public PCs (but we still want to let the user somewhat diagnose the problem via KDB-via-KMS). Later we might want to implement password-protected "unlock" command (with the hash of the password passed via some sysfs attribute). There are a few patches, some are just cleanups, some are churn-ish cleanups, but inevitable. And the rest implements the mode -- after all the preparations, everything is pretty straightforward. Thanks! Anton. -- include/linux/kdb.h | 20 ++-- kernel/debug/kdb/kdb_bp.c | 24 ++--- kernel/debug/kdb/kdb_main.c | 189 +++++++++++++++++---------------- kernel/debug/kdb/kdb_private.h | 3 +- kernel/trace/trace_kdb.c | 4 +- 5 files changed, 125 insertions(+), 115 deletions(-)

12 years, 7 months

Fwd: [ACTIVITY] (Linus Walleij) 2012-11-11 - 2012-11-19

by Linus Walleij

Items of public interest from 1:1 protocol... On Mon, Nov 19, 2012 at 9:22 PM, Deepak Saxena <dsaxena(a)linaro.org> wrote: > On 19 November 2012 02:03, Linus Walleij <linus.walleij(a)linaro.org> wrote: >> * Intense activity on pinctrl and gpio trees, also sending >> a second round of pull requests for fixes to Torvalds >> for GPIO. > > Is this work beyond what's in the two BPs below? If not, can you > create BPs for sort of random maintenance work that comes up and just > throw things on there as they come up? We're still trying to sort out > the best way to use the BPs but there's a lot of pressure to make sure > that we have good tracking of all the work we're doing. So this has basically been just collecting patches that people send on the mailing list, ask a question, git commit --amend to add an ACK, push -next branches etc to the git servers etc. It adds up. I don't know how to properly encode that into a blueprint without the detailing taking more time than the actual work, shall I create a blueprint named "pinctrl maintenance" and "gpio maintenance" and just push in weekly TODO items there with titles like "monitor mailing list", "extract patches", "apply patches", "push branches", "read Rothwells merge log", etc? >> * Sent a patch set to move the Integrators over to the SoC >> bus (Lee's invention) when booting from device tree, >> and at the same time find a natural place to define >> system controller registers. This is meant as a good >> example of how to use the SoC bus. > > -EANOTHERBUS? How does the SoC bus compare to the newly proposed > Capebus. What does it offer that is not already in the platform bus? I'm not familiar with the Capebus... This one was discussed between Lee, Greg and Arnd and they agreed that this was the way to create a container for all the peripherals on an SoC. > PPC went down the path of having an "Off-Chip Peripheral Bus" to > describe devices and then threw it all away a few years ago, so > wondering how this compares. So this is an on-chip peripheral bus. It will group typically AMBA (PrimeCell) and platform devices that sit in the same die. Check commit: 74d1d82cdaaec727f5072eb1c9f49b7e920e076f Yours, Linus Walleij

12 years, 7 months

Questions For Generic Timer Frequency On Fast Model

by Leo Yan

hi all, Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly. In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp. I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate. -- Thx, Leo Yan

12 years, 7 months

[ACTIVITY] (Linus Walleij) 2012-11-11 - 2012-11-19

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Intense activity on pinctrl and gpio trees, also sending a second round of pull requests for fixes to Torvalds for GPIO. * Debated default-hogging of pinctrl handles. We NACKed the idea to use notifications to obtain hogs as it can't handle deferred probes properly, instead we will attempt to push this to the device driver core. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-notifyhog * Probably finished the GPIO-range blueprint work, but need to switch the U300 over to this mechanism as a trial platform: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo… * Sent a patch set to move the Integrators over to the SoC bus (Lee's invention) when booting from device tree, and at the same time find a natural place to define system controller registers. This is meant as a good example of how to use the SoC bus. * Had a final look at Synaptic's RMI4 patch set, I've reviewed all that I can, now it remains for Dmitry and Greg to review the final pieces of the architecture. * Initial Integrator/IM-PD1 patches being cooked. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9 or so. (Make no promises, make no commitments...) * 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

12 years, 7 months

[ACTIVITY] (Dong Aisheng) 2012-11-13 - 2012-11-19

by Dong Aisheng

=== Highlights === * KVM/ARM VGIC state saving and restoring implementation. 1) read the full software emulated gic code hw/arm_gic.c to understand the original gic_state using 2) started to define the standard ABI of gic state for user space to use. The work consists of two part: kernel vgic part and user level qemu part. I would firstly complete kernel vgic part. During the process, mainly two problems met: Firstly, unlike kvm_pic_state of x86, the gic_state, mainly used by fully sw emulated gic in hw/arm_gic.c, is not used by kernel vgic code and most of its members are also not used by hw assisted hw/kvm/arm_gic.c code, i probably need define a new standard gic state structure interface in kvm_irqchip for qemu to use, may be named kvm_gic_state. Secondly, currently i only know to the test method via savevm on a single virtual machine, this is the first target. In the future, we may support multi targets. Will keep going as this and send patch first. * Reviewed a few imx pinctrl patches * Invovled with a few FSL internal meetings on the i.MX changes.

12 years, 7 months

[ACTIVITY] (Rajanikanth H V) 2012-11-12 to 2012-11-16

by Rajanikanth HV

==== Activity Summary ==== - Implemented review comments from Francesco, waiting for ack. - Pinged Rob for review comments and ack - Rebasing ab8500-dt patch set to 3.7-rc5 - Discussion with Arnd on my new blueprint: "impact on kernel size for multi-platform configs" Thanks arnd for his useful inputs - Updated in my Blue Print with the detailed work items ==== Plan ==== - Rebase (manually) ab8500 DT patch and test - Review and rework on the work items details and proceed accordingly ==== Issues ==== 2 days holiday

12 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel